Single Responsibility Principle

In this article, I am going to discuss the Single Responsibility Principle with example. Please read our previous article before proceeding to this article where we discussed the basics of the SOLID Design Principle.

The letter S in SOLID stands for the Single Responsibility Principle which is also known as SRP.

Here is the list of the blogs in this series:

1. Understand SOLID Principle
2. Open-Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

What is the Single Responsibility Principle?

The Single Responsibility Principle states that “Each software module or class should have only one reason to change”. In other words, we can say that each module or class should have only one responsibility to do.

So we need to design the software in such a way that everything in a class or module should be related to a single responsibility. That does not mean your class should contain only one method or property, you can have multiple members (methods or properties) as long as they are related to a single responsibility or functionality.

So, with the help of SRP, the classes become smaller and cleaner and thus easier to maintain.

How can we achieve the Single Responsibility Principle?

Let us understand the need for the Single Responsibility Principle with an example. Suppose we need to design an Invoice class. As we know an Invoice class basically used to calculate various amounts based on its data. The Invoice class does not know how to retrieve the data, or how to format the data for display, print, logging, or sending an email, etc.

If we write the database logic, business logic as well as the display logic in a single class, then our class performing multiple responsibilities. Then it becomes very difficult to change one responsibility without breaking the other responsibilities. So, by mixing multiple responsibilities into a single class, we are getting the following disadvantage,

1. Difficult to understand
2. Difficult to test
3. Chance of duplicating the logic of other parts of the application.

Example of without the Single Responsibility Principle:

As you can see in the above image, we are going to create an Invoice class with four functionalities such as Adding and Deleting Invoices, Error Logging as well as Sending Emails. As we are putting all the above four functionalities into a single class or module, we are violating the Single Responsibility Principle. This is because Sending Email and Error Logging is not a part of the Invoice module.

The following is the complete code and it is self-explained, so please go through the example.

public class Invoice {
    public void AddInvoice() { }
    public void DeleteInvoice() { }
    public void SendInvoiceEmail(MailMessage mailMessage) { }
    public void ErrorLogging() { }
}

Now let us discuss how to implement the above functionalities in such a way that, it should follow the Single Responsibility Principle.

Here as you can see that we can separate ErrorLogging by creating a class named ErrorLogger, which will do only task related to Logging an error.

public class ErrorLogger {
   public void doErrorLogging() { }
}

We can also separate SendEmail by creating InvoiceEmail class. So InvoiceEmail class will do only task related to send email.

public class InvoiceEmail {
   public void SendInvoiceEmail(MailMessage mailMessage) { }
}

So, finally our Invoice class has only single responsibility which is managing Invoice.

public class Invoice {
    public void AddInvoice() { }
    public void DeleteInvoice() { }
}

So, we have learned what is Single Responsibility Principle, how we can achieve it, I hope you understood the need and use of the Single Responsibility Principle. In the next article, I am going to discuss the Open-Closed Principle with a real-time example.

Thanks for reading this article ❤

If I got something wrong? Let me in the comments. I would love to improve.

Clap 👏 If this article helps you.

Follow me on Twitter.