Consider this example:
I have a website. It allows users to make posts (can be anything) and add tags that describe the post. In the code, I have two classes that represent the post and tags. Lets call these classes Post
and Tag
.
Post
takes care of creating posts, deleting posts, updating posts, etc.
Tag
takes care of creating tags, deleting tags, updating tags, etc.
There is one operation that is missing. The linking of tags to posts. I am struggling with who should do this operation. It could fit equally well in either class.
On one hand, the Post
class could have a function that takes a Tag
as a parameter, and then stores it in a list of tags. On the other hand, the Tag
class could have a function that takes a Post
as a parameter and links the Tag
to the Post
.
The above is just an example of my problem. I am actually running into this with multiple classes that are all similar. It could fit equally well in both. Short of actually putting the functionality in both classes, what conventions or design styles exist to help me solve this problem. I am assuming there has to be something short of just picking one?
Maybe putting it in both classes is the correct answer?
Best Answer
Like the Pirate Code, the SRP is more of a guideline than a rule, and it's not even a particularly well-worded one. Most developers have accepted the redefinitions of Martin Fowler (in Refactoring) and Robert Martin (in Clean Code), suggesting that a class should only have one reason to change (as opposed to one responsibility).
It's a good, solid (excuse the pun) guideline, but it's almost as dangerous to get hung up on it as it is to ignore it.
If you can add a Post to a Tag and vice versa, you haven't broken the single-responsibility principle. Both still only have one reason to change -- if the structure of that object changes. Changing the structure of either one does not change the way it is added to the other, so you are not adding a new "responsibility" to it.
Your final decision should really be dictated by the functionality required on the front end. There will likely be a need to add a Tag to a Post at some point, so do something like the following:
If, later, you find a need to add Posts to Tags as well, just add an addPost method to the Tag class and a referenceTag method to the Post class. Obviously, I have named them differently so that you don't accidentally cause a stack overflow by calling addTag from addPost and addPost from addTag.