Single Responsibility Principle

The first principle of SOLID is the single responsibility principle or SRP. It states that the class would have only one reason to change. This means

• A class should have only one responsibility.
• There would not be more than one reason to change the class.

This means that every class in your code should have only one job. Everything in the class should be related to that single purpose. It does not mean that your classes should only contain one public method, there may be many methods as long as they relate to a single responsibility.

A class should have one and only one reason to change – Robert C. Martin

The SRP is roughly the same as having “high cohesion” A class is said to have high cohesion if its behaviors are highly related and strongly focused. The SRP states that a class should be cohesive to the point that it has a single responsibility, where responsibility is defined as “a reason for the change.”

Benefits

• Classes in the projects become smaller and cleaner, which are easier to maintain, understand and explain. 
• The SRP makes the software easy to implement and prevents unexpected side effects from future changes.
• Your code is easier to test when it does exactly one thing because you only need to test for that one thing.
• If a class has multiple responsibilities, and only one is needed in another area of software, the other unnecessary responsibilities hinder reusability. Having a single responsibility means the class should be reusable without modification. 

The single responsibility principle example

The below class violates the SRP. The Employee class has two responsibilities.

• The first responsibility is to calculate the salary of the employee
• The second responsibility is to create employee records whenever a new employee is added.

package com.logicalconstant;

public class Employee {
    public static double calculatePay(String employeeId){
        double pay=0;
//        complex logic to calculate the pay
        return pay;
    }

    public static void createEmployee(String employeeId, String employeeName){
//     complex logic to save a new employee to database
    }
}

Suppose we have two modules using this class: ‘payrollModule’ and ‘HRModule.’

• ‘payrollModule’ uses the ‘Employee’ class to calculate the employee salary.
• ‘HRModule’ uses the ‘Employee’ class to add employee records.

There are at least two reasons for the change in the Employee class (as it has two responsibilities used by two different modules)

• Changes to ‘HRModule’ may cause the Employee class to change. (as HRModule’ module depends on the ‘createEmployee’ method of the Employee class.
• Changes to ‘PayrollModule’ may cause the Employee class to change. (as the ‘payrollModule’ module depends on the ‘calcuatePay’ method of the Employee class.

The violation of the SRP causes several nasty problems. suppose a change to the ‘HRModule’ causes the ‘Employee’ class to change for some reason, that change may force us to rebuild, retest, and redeploy the ‘payrollModule’. If we forget to do this, that model may break unpredictably.

A change in the calculate pay module is no longer independent of the addEmployee module. A change in one will lead us to rebuild, retest and redeploy the other.

A better design is to separate the two responsibilities into two completely different classes. We can refactor the code to split the functionality of this class into two classes in line with the SRP. Now changing the functionality of one will no longer affect the other.

package com.logicalconstant;

//This class is not a violation of the single responsibility principle
public class CreateEmployee {
    public static void createEmployee(String employeeId, String employeeName){
//     complex logic to save a new employee to database
    }
}

CreateEmployee is now independent of CalculatePay.

package com.logicalconstant;

//This class is not a violation of the single responsibility principle        
public class CalculatePay {
    public static double calculatePay(String employeeId){
        double pay=0;
//        complex logic to calculate the pay
        return pay;
    }
}

Using SRP does not necessarily mean that our class should have one public method and do one thing only. It should only has one reason to change