sale.submit() or submitter.submit(sale)
in [OOP]
|
Prev: Excellent Consultants Available for Different Position
Next: Call for Papers: The 2008 International Conference of Systems Biology and Bioengineering (ICSBB 2008)
From: greatlord_5 on 27 Jan 2008 11:24 Hi, I am a newbie to OOD. The application that I am currently designing and developing has a situation similar to the following. There is a sale that has to be posted to a ledger. The ledger is on a mainframe and the sale comes from the web. The operation of submitting the sale to the ledger is a big one and can be successful, failed or undefined. There are several different kinds of sales, such as OTCSale, WebSale, PhoneSale and so on. They are different enough to merit different classes. However, they are submitted to the mainframe in more or less the same way. My question is this: Should the sale object have a submit operation in it? Or should there be a separate Submitter class which accepts different kinds of sale objects? 1. If the sale object has a submit operation, the hierarchy is this: Sale class -----> base class .... OTCSale .... WebSale .... PhoneSale ---------------> 3 sale classes that derive from base Sale one. The base Sale class will have a submit operation which is overriden in each child sale class. Thus, OTCSale.Submit(), WebSale.Submit(), etc. 2. If there is a separate Submitter class, then in addition to the hierarchy in case 1(except submit operation), I need to have an overloaded Submit operation in that class. Thus, Submitter.Submit(OTCSale), Submitter.Submit(WebSale), etc. Why should I choose one over the other? They both look reasonable to me. In the future, if the submit operation changes a bit, one need only change the Submitter class. But this operation has been pretty stable so far. So is this a valid concern? Thanks
From: Nanne on 27 Jan 2008 14:15 On 27 jan, 17:24, greatlor...(a)fastmail.fm wrote: > 1. If the sale object has a submit operation, the hierarchy is this: > Sale class -----> base class > ... OTCSale > ... WebSale > ... PhoneSale ---------------> 3 sale classes that derive from base > Sale one. > > The base Sale class will have a submit operation which is overriden in > each child sale class. > Thus, OTCSale.Submit(), WebSale.Submit(), etc. > > 2. If there is a separate Submitter class, then in addition to the > hierarchy in case 1(except submit operation), I need to have an > overloaded Submit operation in that class. > Thus, Submitter.Submit(OTCSale), Submitter.Submit(WebSale), etc. I'm suspecting that the submitter is not the object you want to use but it will give you an idea, you can create the following table: Submitter/Sale | PhoneSale | WebSale | OTCSale | --------------------------------------------------------------------------- Submitter | submit() | submit() | submit() --------------------------------------------------------------------------- With this table you can decide the following, example 1: PhoneSale: submit(Submitter submitter) WebSale: submit(Submitter submitter) OTCSale submit(Submitter submitter) Or the other way around (example 2) Submitter: submit(PhoneSale phoneSale) submit(WebSale webSale) submit(OTCSale otcSale) In the first example it is easy if you want to add an extra sale, you create a class for the new sale and implement the submit method. In the second example it is harder to add a new sale. You will need to add a method to submit the sale to every implementation of the submitter. In your case if the submitter is the only one, it doesn't make a real difference. But making such a table can help you decide how the implement the objects. HTH, N.
From: Daniel T. on 27 Jan 2008 20:17 greatlord_5(a)fastmail.fm wrote: > I am a newbie to OOD. The basic philosophy says, prefer methods that inform the object of external state changes. > There is a sale that has to be posted to a ledger. The ledger is on a > mainframe and the sale comes from the web. The operation of submitting > the sale to the ledger is a big one and can be successful, failed or > undefined. A basic handshake protocol will suffice. No need to add a submitter class is there?
From: H. S. Lahman on 28 Jan 2008 10:53
Responding to Greatlord_5... > There are several different kinds of sales, such as OTCSale, WebSale, > PhoneSale and so on. They are different enough to merit different > classes. However, they are submitted to the mainframe in more or less > the same way. > > My question is this: > Should the sale object have a submit operation in it? Or should there > be a separate Submitter class which accepts different kinds of sale > objects? That depends on what is involved in submitting. If all the submit does is package the object's <unique set of> attributes into a data packet to send to the server, you first choice is fine because the differences are tied to the nature of the Sale object. OTOH, if the submit needs to work through some exotic network protocol and/or the formatting issues are complicated (e.g., breaking up message packets), then that sort of thing does not logically belong to a sale. So you would likely delegate that to another class. In that case, if the individual submit processing was different for each type of sale you might look at the GoF Strategy pattern for that delegation. -- There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH |