C#

An introduction to Single Responsibility principle (SRP)

Ricardo Sanchez

Ricardo Sanchez

— 2 min read

This is the fifth and last article describing SOLID principles. This article is about the Single Responsibility principle. Hopefully it will help you understand what the principle is all about and why it’s important to keep it in mind when designing and writing your code.

What is the Single Responsibility principle?

Here is the definition from Wikipedia: The term was introduced by Robert C. Martin in an article by the same name as part of his Principles of Object Oriented Design, made popular by his book Agile Software Development, Principles, Patterns, and Practices. Martin described it as being based on the principle of cohesion, as described by Tom DeMarco in his book Structured Analysis and Systems Specification.

In my own words, the Single Responsibility principle is about keeping your classes simple by assigning one responsibility whenever possible. In other words, a class should have one, and only one reason to change. For example, the Reservation class I used as an example in an earlier article is below.

public class Reservation
    {
        public void ProcessReservations(ReservationDetails reservation)
        {
            // business logic, validation, etc...

            // save booking to database
            new ReservationDatabase().Save(reservation);
        }
    }

This class has clearly just one responsibility and it doesn’t violate the SRP as its only responsibility now is to validate data and call a data access layer to persist the reservation data. Since it only has one responsibility, it also has only one reason to change.

An example of Single Responsibility principle violation

If we added code to the same class so the user receives an email notification once the reservation is saved, it would look like this:

public class Reservation
    {
        public void ProcessReservations(ReservationDetails reservation)
        {
            // business logic, validation, etc...

            // save booking to database
            new ReservationDatabase().Save(reservation);
        }

        public void SendConfirmationEmail();
    }

It looks simple right? However, we just introduced a new reason for this class to change. Every time we needed to change how the class saves the reservation or how it sends a confirmation email we’ll need to change it. We don’t want a class to be impacted by these two completely different forces. The new code above violates the SRP.

How to satisfy the Single Responsibility principle

The simple concept of satisfying the SRP is to make sure our class does one thing. This also applies to other bits of code, a single line of code, a variable, a project, etc…

One way to satisfy the SRP in the example above will be to create a new class with the code that takes care of sending email messages. Code that handles email notifications should not be part of this Reservation class.

You need to think hard when writing code to make sure the different bits of code are only responsible for one thing whenever possible. This is difficult but the result is code that is easy to change and maintain. Most bugs created when changing existing code are the result of violating this principle.

This is the 5th and last article about SOLID principles, I hope this can help you understand these principles better and help you write more maintainable and solid code.

Happy Coding!

Read more