[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
