Design – Struggling with the Single Responsibility Principle

coding-styledesigndesign-patternssingle-responsibility

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:

// C-style-language pseudo-code
class Post {
    string _title;
    string _content;
    Date _date;
    List<Tag> _tags;

    Post(string title, string content) {
        _title = title;
        _content = content;
        _date = Now;
        _tags = new List<Tag>();
    }

    Tag[] getTags() {
        return _tags.toArray();
    }

    void addTag(Tag tag) {
        if (_tags.contains(tag)) {
            throw "Cannot add tag twice";
        }

        _tags.Add(tag);
        tag.referencePost(this);
    }

    // more stuff here, obviously
}

class Tag {
    string _name;
    List<Post> _posts;

    Tag(string name) {
        _name = name;
    }

    Post[] getPosts() {
        return _posts.toArray();
    }

    void referencePost(Post post) {
        if (!post.getTags().contains(this) || _posts.contains(post)) {
            throw "Only reference a post by calling Post.addTag()";
        }

        _posts.Add(post);
    }

    // more stuff here too
}

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.

Related Topic