Yes ... the point they were making, and i think its a very good one, is not to try and mimic the real world in the object world and create manager objects to handle actions like these.
Otherwise you wind up trying to encapsulate the knife and the person spreading and the silverware drawer in a manager of some sort and that's irrelevant to the system. They chose the ingredent over the slice because the ingredient knew how thick or chunky it was, hence it could do a better job of spreading itself than the slice. The point being that the ingredient would be aware of any properties that could affect the way it was spread. I like this way of thinking because it eliminates the "doer" as a entity in the model. They are saying that if something is done to an object in the real world, let the object do it to itself in the object world. Things become much more transparent this way. Obviously the slice and ingredient would need to collaborate - otherwise if the slice were in charge of the spreading as you describe the relationship, how would it know what to spread? You could wind up with ANYTHING spread on your bread - Personally, i'd perfer licking the peanut butter off a plate than risking eating who knows what off that bread slice! :)) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barney Boisvert Sent: Monday, December 08, 2003 9:28 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Why not have DAO in BO? I'm not sure the ingredient object is the quite right one. Given this: Ingredient pb = new PeanutButter(); Ingredient j = new Jelly(); Slice top = new Slice(); Slice bottom = new Slice(); This makes the most sense to me: top.add(pb); top.respread(); // calls spread() on all added objects bottom.add(j); bottom.respread(); Spreading requires knowledge of what the "thing" is being spread on, so it can't reside solely in the ingredient object. The problem didn't address the issue of telling the ingredient what to spread on, which is probably more essential than the actual spreading action. I'd rather have a PB&J with an unspread glob of each on the bread than have spread the PB and J all over some arbitrary thing (plate, counter, self). And while passing the slice to the ingredient is unavoidable, it seems that the slice should be in control of the spreading, even if it doesn't do the actual action. Thoughts? I love these kinds of puzzles, the moreso because there is never an absolutely "right" answer. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Nando > Sent: Monday, December 08, 2003 12:06 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Why not have DAO in BO? > > I've been reading Streamlined Object Modeling as of late, and > they would say to put > functions like these in whatever object had the (most) > information to perform the > calculation. I especially like the quote on page 99 where > they are talking about how > to model a peanut butter and jelly sandwich. The question? > Which object of the P&JS > spreads the ingredient. is it (a) the sandwich, (b) the > slice, (c) the ingredient, or > (d) the ingredient-manager. And they write: > > "If you answered (d), please go back to the beginning of the > book and start over. " > > They choose the ingredient object - it applies itself because > it knows more about > itself than the bread slice or the sandwich. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Gabriel Roffman > Sent: Monday, December 08, 2003 6:40 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Why not have DAO in BO? > > > Yes, but if BOs are just a package of instance data, then > where would you > put functions on that instance data. For example, if you > have a shopping > cart and you want the cart to have a calculateTax() function, would > calculateTaxbe part of the BO or part of a manager of the BO? > > > > Hmm, lets say you wanted to initialize the objects instance > data from a > > form, or some other mechanism other than the dB? I have > gone with the > idea > > that the BOs are fairly light weight, they simply package > instance data, > and > > perform very limited validation on themselves. That way they can be > > populated in a verity of ways....form data, dB data, > whatever. The DAO in > my > > apps serves as the go between for the BOs and the > Persistence Mechanism. > > Does that make sense? > > > > Justin > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
