Single Responsibility Principle — SOLID Principles

The Single Responsibility Principle (SRP) states that a class should have only one reason to change. It was first cited in this form by Robert C. Martin in an article that later formed a chapter in his Principles, Patterns, and Practices of Agile Software Developmentbook.

Single responsibility means that each part of the software should have one and only one responsibility to perform. This helps to reduce complexity and ensure that an individual part of the system can be changed and maintained more easily. Examples of single responsibility include a class that manages data storage, a class that handles user input, and a class that performs calculations.

This principle helps promote greater code maintainability and reusability. It also leads to simpler, more cohesive modules and classes, since the number of responsibilities, and therefore the complexity of the code, is kept low. The single responsibility principle can also improve code readability and reduce the probability of side effects caused by code changes.

The benefits of the single responsibility principle are that it can improve maintainability and reduce the complexity of a program. By keeping class and function responsibilities separate, the structure of an application becomes easier to understand and maintain, and changes to a single part of the program will not necessitate changes to other parts. This, in turn, makes it more reliable and easier to debug. Additionally, since each responsibility is narrowly focused, it can be implemented more efficiently, resulting in better performance. Finally, this principle also encourages code reuse, since related features can be imported from other parts of the program, rather than creating duplicate code.

Consider the example below:

public class Order {

     public void product() {
         // product responsibility
     }

     public void stock() {
         // stock responsibility
     }

     public void orderEmail() {
         // sendEmail responsibility
     }

}

The class above violates the single responsibility principle. Why?

This Order class has three responsibilities — product, stock, and sending out emails to customer.

The code above will work perfectly but will lead to some challenges. We cannot make this code reusable for other classes or objects. The class has a whole lot of logic interconnected that we would have a hard time fixing errors. And as the codebase grows, so does the logic, making it even harder to understand what is going on.

Imagine a new developer joining a team with this sort of logic with a codebase of about two thousand lines of code all congested into one class.

Now let’s fix this!

public class product {
    public void showProduct() {
        // product class, showProduct responsibility
    }
}

public class stock {
    public void calculate_Stock_Number() {
        // stcok class, calculate_Stock_Number responsibility
    }
}

public class orderEmail{
    public void sendEmail() {
        // orderEmail class, sendEmail responsibility
    }
}

Now we’ve separated each functionality in our program. We can call the classes anywhere we want to use them in our code.

The examples we used use just showed each class having one method — this is mainly for simplicity. You can have as many methods as you want but they should be linked to the responsibility of the class.

Now that we have separated the logic, our code is easier to understand as each core functionality has its own class. We can test for errors more efficiently.

The code is now reusable. Before, we could only use these functionalities inside one class but now they can be used in any class.

The code is also easily maintainable and scalable because instead of reading interconnected lines of code, we have separated concerns so we can focus on the features we want to work on.

You can follow to be informed about blog posts and not to miss new articles.