Single Responsibility Design Principle – SRP

Single Responsibility Design Principle - SRP

SINGLE RESPONSIBILITY PRINCIPLE (SRP) 

Jayapriya Ravichandran <jayapriya.r@mitosistech.com>

 The basis for this principle is cohesion. Cohesion represents the measure to which a class performs a single function.

Why do we need SRP Principle

  • Classes that are highly cohesive are easier to understand.
  • They are also easier to maintain. This is the motivating force behind SRP.
  • high cohesion is associated with several desirable traits of software includingrobustness, reliability, reusability, and understandability

How do we ensure SRP Principle

If a class has more than one reason to change, then it stands to reason that the responsibilities of that class that are the cause of change should be separated into multiple classes

Cohesion measures the degree to which an entity does a single thing.

This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility

Example:

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.
  1. 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

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:

The Single Responsibility Principle represents a good way of identifying classes during the design phase of an application and it reminds you to think of all the ways a class can evolve. A good separation of responsibilities is done only when the full picture of how the application should work is well understood.

written by  : Jayapriya Ravichandran <jayapriya.r@mitosistech.com>

Recommended Posts

Comments

  1. SRP ensures high cohesion in design principle, good example : ramarkanna@gmail.com

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>