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). 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 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 guess I'm still not clear on what the appeal of segregating Articles and Comments is. On Wed, 12 Jan 2005 09:04:30 -0500, Patrick McElhaney <[EMAIL PROTECTED]> wrote: > I know Scott has decided on a with a solution, but I'd like to > continue this fruitful discussion. > > On Tue, 11 Jan 2005 17:38:41 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > > It was last night when I realised that there is no real concrete > > relationship between Article and Comment as at the end of the day an Article > > can exist without comments > > I'm curious why everyone is asking, "Can an article exist without > comments?" I've been asking myself the opposite question: "Can a > comment exist without an article?" In a typical blog, I think the > answer is no. That's why I think comments should be tucked away under > articles. > > Since you can't retrieve a comment without knowing the article to > which it belongs, doesn't it make sense just to get the comments by > traversing the article? Why burden a higher level module with the > repsonsibility of managing that relationship? And if an article knows > about its comments, why not just store the comments when you store the > article, freeing the higher level module from that burden as well? > > <cf_tangent> > When I encounter a room full of unruly objects, the first thing I do > is ask each of them why they're there. Invariably, many of them will > say, "Because so and so dragged me here." I send those objects out of > the room so I can focus on what the primary objects are doing. > </cf_tagent> > > > so if I were to feed that down the uber DAO > > pipe, it would have to do some logic to firstly determine if a comment > > exists, how many and save them... > > I don't think you need an if statement to determine whether an article > has comments. An article will always have a /collection/ of comments. > That collection may be empty -- and it always is initially -- but it's > still there. > > Patrick > > -- > Patrick McElhaney > 704.560.9117 > http://pmcelhaney.blogspot.com > ---------------------------------------------------------- > 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]
