Hehe... I suppose we've all been taught a lesson on designing a system
with no referenceable requirements!

On Thu, 13 Jan 2005 17:31:47 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>  
> 
>   
> [trim] 
> 
> > > (Article.addComment()) 
> > 
> > I was always operating under the assumptions that an article 
> > is a blog entry and blog entries can always have comments. 
> > Maybe comments are turned on and off of individual entries. 
> > An article would know whether it's accepting comments 
> > (article.acceptsComments()).  The addComment() function would 
> > thrown an exception of you call it on an article that's not 
> > accepting comments. 
> > 
> > I also haven't taken into consideration the notion that 
> > comments could apply to something other than blog entries. 
> > 
> > When the problem is framed that way do you still think 
> > articles need to be decoupled from comments? 
> 
> Hehe well this also shows that there is no real right or wrong way of doing
> it? I mean if a developer wants to say articles will always have comments,
> it's a hard fast rule - coupling is ok then as its now part of the articles
> concept.. Its like saying a listBox will always have a collection of OPTIONS
> even though a listBox has other functionality unto itself. 
> 
> I prefer in generic terms to decouple comments and articles and use
> something to aggregate them, because I know that comments are a generic
> enough object to be re-used (the web illustrates this). An Article is also
> something that has certain amount of agility - you could argue "Articles
> Extends Comment" as an article really is someones comment on a topic....
> (semantic abuse I grant you but...) 
> 
> It varies but for say a blog - I guess you could get away with it quite
> cleanly by coupling a blogEntry to a Comment. 
> 
> Its like in a Mach-II Config where a "Filter" has "Parameters" while a
> filter can exist without parameters, it still has an option to add them. I
> think the only real argument to put on the table when designing this systems
> is "will this child be re-used in other objects or better yet shared". If
> that answer is yes, break the relationship away imho. 
> 
> Scott 
>
----------------------------------------------------------
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]

Reply via email to