I'm not sold either way 100% but I'll toss in my 2 cents and see where it leads me ;)
" The article object should hold the knowledge of all its comments, not the manager." The manager doesn't hold the comments, I think the suggestion here is that the DAO responsible for the article should not be specifically tied to the comment DAO. In my case the Article BO would still contain an array/collection of comment objects as a property. " you can call something like Article.addComment( commentTO )," I can still call that... " the manager objects can simply coordinate action between the different layers (persistence/DAO, business objects, caching, etc.)." Exactly, when it's time to 'persist' my manager would utilize the article and comment DAOs respectively. (As opposed to extracting and looping on the comments inside the article DAO). -Stace -----Original Message----- From: Doug Keen [mailto:[EMAIL PROTECTED] 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). 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. <table width=800 cellpadding=4 cellspacing=10 border=0><tr bgcolor=BDBDBD><td valign=top width=400><font face=verdana size=2 color=FFFFFF><b>AVIS IMPORTANT</b></font></td><td valign=top width=400><font face=verdana size=2 color=FFFFFF><b>WARNING</b></font></td></tr><tr><td valign=top width=400><p align=justify><font face=verdana size=1 color=808080> Les informations contenues dans le present document et ses pieces jointes sont strictement confidentielles et reservees a l'usage de la (des) personne(s) a qui il est adresse. Si vous n'etes pas le destinataire, soyez avise que toute divulgation, distribution, copie, ou autre utilisation de ces informations est strictement prohibee. Si vous avez recu ce document par erreur, veuillez s'il vous plait communiquer immediatement avec l'expediteur et detruire ce document sans en faire de copie sous quelque forme.</td><td valign=top width=400><p align=justify><font face=verdana size=1 color=808080> The information contained in this document and attachments is confidential and intended only for the person(s) named above. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution, or any other use of the information is strictly prohibited. If you have received this document by mistake, please notify the sender immediately and destroy this document and attachments without making any copy of any kind.</td></tr></table> ---------------------------------------------------------- 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]
