Single Responsibility Principle ☝️

We’ve all been there, you start a new project with high hopes. Start creating new classes and making cool things. But as you code you realize that one class keeps getting bigger. It grows and it grows and while you see it happening, you let it slide. When you eventually do take the time to take it apart, you realize that it all kind of interlocks. Moving it to separate classes becomes harder and harder as it keeps eating at you in the back of your mind.

Until that inevitable moment where you let out a deep sigh, grumble to yourself and accept that you need to do a complete refactor and rewrite of the class.

To prevent this problem from happening, programmers came up with design principles. The design principle we’ll be talking about today is the Single Responsibility Principle.

📚 Definition

The Single Responsibility Principle is the first of the five design principles defined in SOLID. SOLID is an abbreviation of the 5 key design principles used in Object oriented programming. The main reason of using SOLID is to create applications that are maintainable and scalable.

SOLID has been well described in many articles and I definitely recommend to read multiple articles to get a better idea of what it is and why SOLID is so relevant. I personally liked this article from Yiğit Kemal Erinç as a general overview and this article by Ugonna Thelma as a super cool visualization of SOLID.

This article and hopefully this series of articles (if I get to it), will go a bit more in depth on each principle of SOLID to better explain the principles in detail. The articles will mainly focus on why to use the principles, where the principles happen and what the advantages are of using these principles.

🤔 What is it

It comes down to that one class should only do one thing.

The official definition of the Single Responsibility Principle actually is

“There should never be more than one reason for a class to change.”

— Source

This definition feels a bit confusing to me. Mainly because the definition explains how to find out if the principle has been violated. But not how to prevent it or what it actually is. So for now let’s just say that it comes down to one class should only ever do one thing and we’ll explain the rest in the upcoming article.

Although the idea that one class should only do one thing is easy to understand, it can be hard to implement. It can be difficult to define when something is doing one or now two things. Defining what a responsibility is and where to draw the line is, is eventually up to you. But there is a way to help you figure it out.

The main tool to find out if this class has one or more then one responsibility, is to ask the following question:

Is there more then one reason to change this class?

If you can think of more then one reason/motivation to change the class, then this class has more then one responsibility.

But this then leaves us with a new question, what exactly is a reason to change?

❓ What is a reason to change?

A reason to change is a motivation to change the class.

“In the context of the Single Responsibility Principle (SRP) we define a responsibility to be “a reason for change” If you can think of more than one motive for changing a class, then that class has more than one responsibility”

— Source

For example, a class that sends emails should only send emails. The only reason to change would be when it incorrectly sends emails(format incorrect, wrong adress, etc.). That means there is only one motivation to change the class. Now imagine that you’d also like this class to store the emails that it sent, that’s pretty reasonable right? Yet this actually violates the Single Responsibility Principle as there would then be more then one reason to change the class.

The reasons/motivations to change are now:

It sends emails incorrectly
It stores emails incorrectly

As it’s now become both an email sender and email storage, it has more then one responsibility and should be split in two.

➗ Dividing up responsibilities

So this is all nice and good but how do you actually implement this? Because doesn’t all code do multiple things?

Let’s look at an example of creating an email sender and storage. We’ll start with a class that just send emails. As we first created this class we thought that the class would be handling all email communication so we called it EmailHandler. But for right now it just sends emails.

public class EmailHandler
{
    public void SendEmail(string emailAdress, string content)
    {
        System.SendEmail(emailAdress, content);
    }
}

This works well, the emails get sent and all is well. But now we also need to store the emails that we’ve sent. So we add a StoreEmail method and store the emails in the EmailHandler.

public class EmailHandler
{
    private List<string> emails = new List<string>();

    public void SendEmail(string emailAdress, string content)
    {
        System.SendEmail(emailAdress, content);
    }

    public void StoreEmail(string content)
    {
        emails.Add(content);
    }
}

Only now we’ve actually violated the Single responsibility principle as it now has two responsibilities.

🗒️ Quick note on naming

Class names do not always equal their responsibilities. It’s important to keep in mind that class names cannot be fully trusted to understand it’s responsibilities.

As it’s hard to define the responsibility, we can go back to checking if there is more then one reason/motivation to change. Is there?

The reasons/motivations to change this class are now:

It sends emails incorrectly
It stores emails incorrectly

As we can see there are now two reasons to change. So that means we need to create two separate classes, one that sends emails and one that stores emails.

public class EmailSender
{
    public void SendEmail(string emailAdress, string content)
    {
        System.SendEmail(emailAdress, content);
    }
}

public class EmailStorage
{
    private List<string> emails = new List<string>();

    public void StoreEmail(string content)
    {
        emails.Add(content);
    }
}

But now the question becomes how do we connect them? There are two ways of doing this:

Connect the EmailSender to the EmailStorage directly
Create a third class that calls them both.

➡️ Connecting two classes directly

Let’s first look at connecting the two classes.

public class EmailSender
{
    private EmailStorage storage = new EmailStorage();

    public void SendEmail(string emailAdress, string content)
    {
        System.SendEmail(emailAdress, content);
        storage.StoreEmail(content);
    }
}

public class EmailStorage
{
    private List<string> emails = new List<string>();

    public void StoreEmail(string content)
    {
        emails.Add(content);
    }
}

This method compartmentalizes both classes with their own responsibilities and connects them. This follows the Single Responsibility Principle correctly as both have a single reason to change.

It’s completely okay for one class to depend on another as long as their code isn’t entangled. The only thing that could be seen as a downside to this approach would be that the EmailSender will now always be dependant on the EmailStorage. This can be a problem when reusing the EmailSender as you might want to re-use it with a different Storage.

🔼 Connecting with a separate class

Now let’s create a third class that calls them both individually. So that we send and email and immediately store it.

public class EmailHandler
{
    private EmailSender sender = new EmailSender();
    private EmailStorage storage = new EmailStorage();

    public void SendAndStoreEmail(string emailAdress, string content)
    {
        sender.SendEmail(emailAdress, content);
        storage.StoreEmail(content);
    }
}

But wait doesn’t this new EmailHandler class also violate the Single Responsibility Principle? Yes it does actually, but the class responsibilities are compartmentalized in different classes. This also shows that in reality some parts in the code will always have multiple responsibilities.

It’s actually okay to have multiple responsibilities in part of your code. All code will have to come together at one point. The Single Responsibility Principle should be used when possible. But unfortunately it won’t work everywhere. That being said when and where it can be implemented. It will make your code more reusable and maintainable.

🗒️ Personal note on talking about class responsibilities

When I start using other people’s code I often ask them about what a specific class does. Which often goes something like:

“Hey, what does this EmailHandler class do?”

“Well the EmailHandler handles emails”.

The answer usually doesn’t include the responsibilities of the class but rather the general idea of what it does. So, I follow up with:

“Hey what does it actually do, what responsibilities does it have? Does it send email? Does it format emails? What does it do, specifically?”

They then come up with the answer that I actually need.

“Oh it sends and stores emails actually”.

This is important to keep in mind when asking and or when explaining to someone what a class does. It can be an important tool to ask about what the responsibility of a class is rather then asking what it does.

✌️ But why should the classes be split in two?

It might be logical to think that because the responsibilities are quite close together, it’s not that bad to integrate them with one another right? Or maybe that it’s not really worth it to separate them, because they both deal with the email part of the application.

Although those are valid cases when an application is small and you’re the only one using it. They evaporate at a rapid pace when the code grows and the code starts being reused. The Single Responsibility Principle is all about maintainability and scalability and achieves this in a number of ways.

🔗 Preventing code coupling

Code often grows quite fast and by interlinking code a bug in one part can cause a bug in the other. By compartmentalizing classes to only do a single thing it will remove the impact on other code. Having a bug in the sending will no longer be able to cause a bug in the storing. This means that when a bug happens, less code is affected making things easier to debug.

🔒 Fewer side effects because of information hiding

When two different responsibilities that are close together are put together in a class. It becomes very easy for them to manipulate each others data in unexpected ways. However when they are put in separate classes. Information hiding can be applied to prevent unexpected ways of manipulating data.

We won’t go too deep into information hiding in this article as it’s out of scope of the article. But in very short, Information hiding or encapsulation is a way to protect data from being accessed or manipulated in unexpected ways.

Once interlocking and accessing data that it shouldn’t starts. It will become harder and harder to split up the class. This is because as the different responsibilities become entangled, they become harder to use independently. This often creates side effects between the responsibilities that increase over time.

♻️ Does not depend on one another (reusability)

It’s a given that at some point the class will need to be reused. When a class has multiple responsibilities the user now automatically has to support both the email sending and storing. But at a certain point the user will want to use just one of them. Less code that is affected will mean less code that can have bugs.

🐋 Classes becoming too big

Software often grows pretty quickly. It’s quite easy to add a method here and there and end up with a file of 500 lines. Big files aren’t inherently bad but they’re definitely a warning sign of code not being compartmentalized enough.

This becomes a bigger problem when classes contain multiple responsibilities as they now grow at a multiplied rate. This will often lead to classes that are so big that they become hard to read and maintain.

Classes becoming too big should be a warning sign that a class has too many responsibilities.

⬆️ Standardization of class interface (reusability)

Often when direct access to the data of a class is available, reusable methods aren’t written. By making multiple classes, the communication between those classes is standardized. This makes the the class re-usable as these methods are accessible to other code as well. Although the standardization of the interface of a class is not a direct benefit of Single Responsibility Design, it can stimulate it.

In the following example we have the old uncompartmentalized EmailHandler. We’ve added a imaginary email class that handles the email data. In this example code we can see that the SendEmail now returns a result and when it fails there is a new method ResendLastEmail that can be called to try to resend the last email.

public class EmailHandler
{
    private List<Email> emails = new List<Email>();

    public bool SendEmail(Email email)
    {
        bool success = System.SendEmail(email);
        StoreEmail(emailAdress, content);
        return success;
    }

    public void ResendLastEmail()
    {
        SendEmail(emails.Last());
    }

    public void StoreEmail(Email email)
    {
        emails.Add(email);
    }
}

This can cause problems because of the following:

Because the email sending can directly access the data of the email storage. It uses the pure data directly in a way that might not be correct. Accessing the data directly instead of creating a method that can be re-used in the future harms re-usability and maintainability.
Stimulates duplicate code as someone else might need the code. As the action isn’t standardized they might just copy past the code.
It entangles the responsibilities together as it directly access data it’s not supposed to.

Now let’s see what happens if we compartmentalize them in separate classes:

public class EmailSender
{
    private EmailStorage storage = new EmailStorage();
    private Email lastSentEmail;

    public void SendEmail(Email email)
    {
        lastSentEmail = email;
        bool success = System.SendEmail(emailAdress, content);
        storage.StoreEmail(content);
        return result
    }

    public void ResendEmail()
    {        
        SendEmail(storage.GetLastStoredEmail(lastSentEmail));
    }
}

public class EmailStorage
{
    private List<Email> storedEmails = new List<Email>();

    public void StoreEmail(Email email)
    {
        emails.Add(email);
    }

    public Email GetLastStoredEmail(Email email)
    {
        //Do some logic that might be important
        return emails.Find(email);
    }
}

By compartmentalizing the classes we were forced to create a new methods that standardized how the EmailStorage data can be spoken to. These methods can then be reused outside of the EmailSender.

🔚 Conclusion

Compartmentalizing responsibilities is something that will make code more reusable, maintainable and scalable.
Making one class do only one thing can be easy to understand but hard to implement.
The later it’s implemented the harder it gets.

👏 Attribution

Special thanks to Guus Hamm for reviewing the article.

📖 Article used and linked

“Single Responsibility Principle” (PDF) by objectmentor.com

The SOLID Principles of Object-Oriented Programming Explained in Plain English Erinç by Yiğit Kemal

The S.O.L.I.D Principles in Pictures by Ugonna Thelma by Ugonna Thelma

Information hiding wikipedia

📚 Definition#

🤔 What is it#

❓ What is a reason to change?#

➗ Dividing up responsibilities#

🗒️ Quick note on naming#

➡️ Connecting two classes directly#

🔼 Connecting with a separate class#

🗒️ Personal note on talking about class responsibilities#

✌️ But why should the classes be split in two?#

🔗 Preventing code coupling#

🔒 Fewer side effects because of information hiding#

♻️ Does not depend on one another (reusability)#

🐋 Classes becoming too big#

⬆️ Standardization of class interface (reusability)#

🔚 Conclusion#

👏 Attribution#

📖 Article used and linked#