Article and Comment classes: Who's responsible for what?

Question

Considering the Law of Demeter, Single Responsibility Principle and Tell, Don't Ask principle; What is the correct relationship between the Article and Comment class?

A: The Comment is a concern of Article class. It can Read, Create, Update and Delete comments. The Comment class itself is just a read-only representation of the Comment concept.

B: The Comment is a concern of HandleComments class. It can Create new comments and assign them to the respective articles. It can also Read, Update and Delete comments. The Comment class itself is just a read-only representation of the Comment concept.

C: The Comment is not a concern of neither Article or HandleComments classes. It has all the CRUD functionality by itself. It can Assign itself to an article as well.

D: The Comment could be a concern of either Article or HandleComments classes; However they can only Read, Create and Delete comments. The Update functionality is a concern of Comment class itself.

Update #1

Here is how I think about it, however can't really find answers because all of my reading ends up to a non-practical or very simple proof-of-concept examples:

• Do I have to have readComment, createCommnet, updateComment and deleteComment classes? According to Bertrand Meyer classes with Verbal or PerformSomething names are signs of danger as they could be methods not classes. So it is okay to have only Article and Comment classes with all of their respective functionality inside themselves?
• The Article and Comment doesn't have a is-a relationship, so obviously no inheritance here, but they have a has-a relationship. I'd go for Composition then, but who's responsible for what? If I am a Comment then this is my concern to Update myself, right? But is that the Article's concern to Delete me? Hence I'm attached to it.
• Is it the concern of Article to load its Comments? Or there should be a man-in-the-middle class to handle the relationship between the Article and Comment? If the Comment has loaded by the Article then is it a concern of Article to be 100% responsible for all of the Comment actions?

Update #2

More thinking about it, what I really want is Loosely-Coupled classes as much as possible. In any case the Article class should have a list of Comments to iterate between them. In order to assign a Comment to an Article, I should either pass the Article reference to the Comment constructor -- the bottom-top way, or I should pass the Comment reference to the AddComment method of Article class -- the top-bottom way.

I prefer the Bottom-Top-Way, even tho it looks awkward in the first sight, because then I can have all the other Comment actions also within the Comment class itself, so the Article class will be totally unaware of Comments class. The only thing the Article class should have is an internal array to hold the Comments instances. No need to have AddComment, RemoveComment methods to the Article class.

Is it something that makes sense?

Answer 1

Thanks to Bart comments, I decided to go for the Repository Design Pattern, which seems to be one of the battle-tested patterns for handling this kind of cases.

The general idea is to have a Repository which is responsible for taking care of Comments. So in a broader view a Blog should have at least a postRepository and commentRepository to take care of blog Posts and Comments functionality.

It is also recommended to handle all of the List like data with repository pattern, when there is a need for a kind of central-functionality. In the Blog example, it make sense to have repositories for Categories, Tags, Users, etc. as well.

Answer 2

Without knowing a lot more about the system it's difficult to answer your question (bar the specifics in update 2). It's possible, for example, to think of comments referencing articles, or articles referencing comments. With more details, especially use cases, it's likely that one design would likely come out in front.

Nevetheless, in the absence of further information, it's your second bullet point, composition, which strikes me as most natural. To wit, articles have a list of comments, as well as a title, a body, etc. You might or might not have a CommentsList intermediate class. In any case, you can create, delete, and get references to comment objects. Comments have text, links, formatting, etc.

Re update 2, I agree that loose coupling is desirable. However I disagree that passing a reference to an Article to the Comment constructor makes sense, all other things being equal. This introduces a cyclic dependency -- because the Article has a list of Comments -- and also therefore a higher degree of coupling than would be the case if you took the alternative "top-bottom" approach of passing the Comment to the AddComment method of the Article class.

With this "top-bottom" approach, the Article could either have a NewComment method, in which case the Article itself creates the Comment object, or it could have an AddComment method as you suggest. Which is preferable depends on the details of the requirements: for example a requirement to have different kinds of comments (or even to share comments between articles) would suggest the AddComment approach.