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

considering law of demeter, single responsibility principle , tell, don't ask principle; correct relationship between article , comment class?

a: comment concern of article class. can read, create, update , delete comments. comment class read-only representation of comment concept.

b: comment concern of handlecomments class. can create new comments , assign them respective articles. can read, update , delete comments. comment class read-only representation of comment concept.

c: comment not concern of neither article or handlecomments classes. has crud functionality itself. can assign article well.

d: comment concern of either article or handlecomments classes; can read, create , delete comments. update functionality concern of comment class itself.

update #1

here how think it, can't find answers because of reading ends non-practical or simple proof-of-concept examples:

• do have have readcomment, createcommnet, updatecomment , deletecomment classes? according bertrand meyer classes verbal or performsomething names signs of danger methods not classes. okay have article , comment classes of respective functionality inside themselves?
• the article , comment doesn't have is-a relationship, no inheritance here, have has-a relationship. i'd go composition then, who's responsible what? if comment concern update myself, right? article's concern delete me? hence i'm attached it.
• is concern of article load comments? or there should man-in-the-middle class handle relationship between article , comment? if comment has loaded article concern of article 100% responsible of comment actions?

update #2

more thinking it, want loosely-coupled classes as possible. in case article class should have list of comments iterate between them. in order assign comment article, should either pass article reference comment constructor -- bottom-top way, or should pass comment reference addcomment method of article class -- top-bottom way.

i prefer bottom-top-way, tho looks awkward in first sight, because can have other comment actions within comment class itself, article class totally unaware of comments class. thing article class should have internal array hold comments instances. no need have addcomment, removecomment methods article class.

is makes sense?

without knowing lot more system it's difficult answer question (bar specifics in update 2). it's possible, example, think of comments referencing articles, or articles referencing comments. more details, use cases, it's 1 design come out in front.

nevetheless, in absence of further information, it's second bullet point, composition, strikes me natural. wit, articles have list of comments, title, body, etc. might or might not have commentslist intermediate class. in case, can create, delete, , references comment objects. comments have text, links, formatting, etc.

re update 2, agree loose coupling desirable. disagree passing reference article comment constructor makes sense, other things being equal. introduces cyclic dependency -- because article has list of comments -- , therefore higher degree of coupling case if took alternative "top-bottom" approach of passing comment addcomment method of article class.

with "top-bottom" approach, article either have newcomment method, in case article creates comment object, or have addcomment method suggest. preferable depends on details of requirements: example requirement have different kinds of comments (or share comments between articles) suggest addcomment approach.