The Principle states that

there should not be more than a single reason for a class to change.

Which means whenever you are modifying a class you should not have more than one reason to modify it. If you have two or more reasons for a class to modify then you are violating the principle. The principle may be stated in a different way, that your class should perform only one responsibility. So, whenever you are making any modifications to it you would always have a single reason to do so. It’s the simplest of all SOLID principles but difficult one to implement.

When I say a class should not have more than a single responsibility, it does not mean that a class should have a single function in it. A class may perform a single responsibility with one or more functions in it. Its very important to understand what does ‘reason for change’ or ‘single responsibility’ means. Following examples would explain all about SRP.

Explanation:

Suppose, we have to write a class that makes a call to the specified mobile number. Before the class would make a call, the mobile number should get validated. So, if the mobile number is valid, its only then the class should make a call otherwise not. One way to implement this is,


public class MakeCallToMobile
{
  public void callMobile(MobileNo mobileNo)
  {
    if(validateMobileNumber(mobileNo))
    {
       //code to make a call on the mobile number
    }
  }

  public boolean validateMobileNumber(MobileNo mobileNo)
  {
    //Verify if the mobile no is valid.
  }
}

If we look at the above approach, everything is fine. The MakeCallToMobile class is exactly serving the purpose i.e  callMobile(MobileNo mobile) would make a call only if its other function validateMobileNumber(MobileNo mobileNo) would return true.

But, the class is a clear violation of SRP: The class is performing two responsibilities

1. Making a call to the specified mobile number.

2. Validating the mobile number.

Problems because of such a design: Because of ever changing requirements in real world, if you need to make a change in the way mobile number is getting validated, the only place where you can modify code is MakeCallToMobile class. If we observe the class it has got one more action to do, which is making a call; which is no way related to this change. But, if you make such a change , you would need to again rebuild and retest the  call mobile functionality. Similarly, if you need to make a change to the way class makes a call to the mobile number, you need to again rebuild and retest  the mobile number validation.  So, making a small change in one responsibility would force us to rebuild and retest the other responsibility also.

You can overcome this problem by following SRP. You create two classes each performing a single responsibility as shown below.


public class MakeCallToMobile
{
  public void callMobile(MobileNo mobileNo)
  {
    if(ValidationeService.validateMobileNumber(mobileNo))
    {
       //code to make a call on the mobile number
    }
  }
}

public class ValidationeService
{
  public static boolean validateMobileNumber(MobileNo mobileNo)
  {
    //Verify if the mobile no is valid.
  }
}

In the above design, since both responsibilities reside in different classes, you are relieved of making a change in one without affecting other in any way. Clearly in the above design, you would have only one reason to make a change in any of the classes. For MakeCallToMobile class, reason to change would be ‘changing the way it makes a call to mobile number’ and for ValidationService class –  reason to change would be ‘changing the way it performs validation of a mobile number’.

Conclusion: Using SRP,

You would achieve better code readability, reduce testing and maintenance efforts and consequently strive for faster development life cycles.