Single Responsibility Principle (SOLID 1/6)

We have heard about SOLID principles and that we should program according to them. But do we know what does it mean? I admit: I don’t actually know. I know just part of it, and less what each letter really means. So I will write a series about them to really learn what SOLID is (even if there are many blog posts about SOLID principles). SOLID is an acronym of the following object-oriented programming principles:

• Single responsibility principle,
• Open/closed principle,
• Liskov substitution principle,
• Interface segregation principle and
• Dependency inversion principle.

Single responsibility principle (SRP) is maybe the easiest of them and anyone can at least guess somewhat what it means. Hopefully easy start for this series.

Definition

A class should have one, and only one, reason to change. (Robert C. Martin)

The original definition by Robert C. Martin isn’t really clear. Isn’t there usually many reasons to change class? How is it possible to have only one reason to change?

I’ve thought that SRP means that for example, a method should do only one thing. If a method name includes “and”, it violates SRP. “SaveAndCalculateSalary” obviously has more than one responsibility. But what does “one reason to change” actually mean?

In the context of the SRP we define a responsibility to be “a reason for change.” (Robert C. Martin)

In SRP, reason can be thought like a requirement. If a class has more than one requirement, it has more than one responsibility.

For example first, we might have a requirement to save log data to files. But later we change that logs have to be saved into a database. Now, if we have coded according to SRP, we have to change only one class, the logging class. But if we have violated SRP, we have to change several classes.

Do one thing and do it well.

In a nutshell, SRP means that do just one thing in a class.

Simple Example

Here is a simplified code that violates SRP:

public class OrderBusiness
{
  public Order CreateNew(...)
  {
    // check some business rules
    var order = new Order(...);
    // insert order to database
    return order;
  }
}

This code has two reasons to change:

• If saving order to database requirement changes or
• If business rules change.

Here is a refactored version:

public class OrderBusinessRefactored
{
  private OrderRepository _orderRepo;

  public Order CreateNew(...)
  {
    // check some business rules
    var order = new Order(...);
    _orderRepo.Insert(order);
    return order;
  }
}

Here I have extracted saving to the database into OrderRepository class. Now if business rules change, it doesn’t affect OrderRepository class. Or if we want to save orders to files, we just make a change to OrderRepository class and OrderBusinessRefactored class isn’t affected.

Hotpot Is a Sign of SRP Violation

Adam Tornhill represented hotpots in his book Software Design X-Rays (read also my blog post about it.) Hotpost is a module, class or function that is big and frequently changed. Hotpost is a clear sign of SRP violation because many developers have to make changes to it all the time. And if it needs constant updates it doesn’t have only one responsibility but many.

Reasons to Apply SRP

By applying SRP we will write more maintainable code because we don’t need to make big code changes. SRP will make code changes easier because each class has only one reason to change.

Waterfall model’s one weakness is that it can’t react quickly to requirement changes. But in the agile software development, we know that requirement changes are inevitable, and agile is designed for changes. Same is with SRP. We know that code and its requirements will change. By applying SRP we can make those requirement changes easier because we have to change only one class.

RSP makes our code more readable because each class will be more simple and short. When there is just one responsibility per class, it makes it much easier to read than a class that has many responsibilities.

Testability also increases with SRP. It is more simple to test a class with only one responsibility. Test cases will be simple and we don’t even have to have many test cases.

According to The Pragmatic Programmer, DRY (don’t repeat yourself) is the most important rule for developers. SRP even helps with this. When our classes do only one thing, they are easier to find and reuse. But if a class has many responsibilities, it is tempting to just write another class with that one responsibility and we’ve violated the DRY principle.

Conclusion

RSP means a class or module that has only one reason to change and a class that does only one thing and does it well. There are many benefits when our code applies SRP:

• Easier to maintain the code,
• React faster to the requirement changes (and we know they will change!),
• More readable and testable code and
• It is easier to write DRY code.

Tip to write code that applies to SRP: keep it simple and write small classes and methods.

Sources and Influences

• Agile Principles, Patterns, and Practices in C# by Robert C. Martin and Micah Martin. Chapter 8, SRP: The Single Responsibility Principle.
• Encapsulation and SOLID by Mark Seemann in Pluralsight.
• Single Responsibility Principle: A Recipe for Great Code by Adel Fayzrakhmanov in Toptal Blog.
• Software Design X-Rays by Adam Tornhill. Chapter 2, Identify Code with High Interest Rates.

Blog Posts in This Series

• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle
• The conclusion