Just goes to show how we all have different takes on these ideas. My thoughts inline...
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Doug Keen > Sent: Wednesday, January 12, 2005 10:04 AM > To: [email protected] > Subject: Re: [CFCDev] When to Use Composition (Was: Newbie approach...) > > Patrick... I wholeheartedly agree. > > I don't think it's a manager object's responsibility to coordinate > collaborations between business objects. The article object should > hold the knowledge of all its comments, not the manager. That way, if > you want to add another comment to the Article, you can call something > like Article.addComment( commentTO ), and then the Article business > object can manage the creation of the Comment object and all the rules > associated with it (e.g., the Article, since it has knowledge of all > its Comments, can make sure this new Comment isn't a duplicate of one > of it's existing comments). I think that an object should either create other objects or use other objects, but not both. Having the Article object creating and manipulating comment objects seems to reduce the cohesion of the Article. Unless you are going all the way to say that they are really part of the same "thing" and in that case just combine them into a single object, maybe "BlogContent". But let's play out the original idea out a bit. OK, you have an ArticleBO. In the interest of separating creation from usage, let's say you're passing in an object to let the ArticleBO deal with Comments. What do you pass into the ArticleBO? A CommentGateway, so the ArticleBO and retrieve all comments associated with it? A prebuilt array of associated CommentBO objects? If you pass in a Gateway you're already crossing the layer between the business objects and the persistence layer. If you pass in an array, and you want to create a comment, now the ArticleBO has to create a new CommentBO and place it into the array. And how does that new CommentBO get persisted? Right now it's just sitting in the array. Somewhere a CommentDAO is going to have to store that new CommentBO. This would also be crossing layers. In other words, I don't see any way for an ArticleBO to get or store new Comments without dealing with a CommentGateway and a CommentDAO, and if that's true then I think cohesion has been sacrificed because Articles are responsible for Articles AND Comments. Not only that but the business object is now coupled to a DAO/Gateway...certainly not a good thing? > Pushing that kind of logic up into the > service layer (i.e., manager objects) seems to contradict cohesion. > Let your business objects take care of all the business logic... the > manager objects can simply coordinate action between the different > layers (persistence/DAO, business objects, caching, etc.). I think from the example I gave above, this situation *is* a situation where one layer (BO) is dealing with another layer (DAO/Gateway). I would indeed push this relationship into a higher layer. > I tend to think of this kind of "manager does everything" approach as > an *anti-pattern*... I'd like to call it the "Micromanager > Anti-pattern". Just like a micromanager doesn't trust subordinates to > do their job and tends to direct every single task to such minute > detail that the workers are simply reduced to an extra set of hands, > "Micromanager" objects take on too many minute details of business > processes and reduce business objects to dumb sacks of data that might > do a few type-checking operations on its instance data and little > more. It's almost as if the manager object methods become procedural > subroutines and the business objects act as simple data structures... > it strikes me as a very non-OO approach. I can see how that would be bad...I'm not advocating handling all relationships with Managers. But I am agreeing with you that a Manager type of object should be coordinating interactions between separate layers like DAOs, Gateways, and BOs. > I guess I'm still not clear on what the appeal of segregating Articles > and Comments is. This might really be the crux of the issue. Do Articles and Comments really need to be modeled as separate "things"? I find all this very interesting! Hey Sean, can we get your take? ---------------------------------------------------------- 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]
