SOLID Part-1 : Single Responsibility Principle - Software design

S O L I D

'S' represents Single Responsibility Principle

Every class should have responsibility over a single part of the functionality provided by the software and that responsibility should be entirely encapsulated by the class. In other words there should never be more than one trigger or reason for a class to change. When a (functional) responsibility is divided over more than one class, all classes’ part of that responsibility has to change.

The code must be maintainable. When we need to make a change in a class having more responsibilities the change might affect the other functionality related to the other responsibility of the class. The code, which cannot adapt to change requirements with ease, is not a well defined.

When we design our classes, we should take care that one class at the most is responsible for doing only one task or single responsibility. Not only should the class, even operations or methods in the class defined in a way that it has only one responsibility to handle. To understand this let us take an example of Employee class. Class Employee is made with few of its attributes and operations.

Class Employee{

            private String employeeId;

            private String name;

            private string address;

            private Date dateOfJoining;

            private Int DesignationId;

 

            public amtIncrement(){

                        //increment logic implementation

            }

            public calDOR(){

                        //Date of retirement logic implementation

            }          

            public setDateOfJoining(){

            }

            public setEmployeeId(){

            }

            public getDateOfJoining(){

            }

            public getDesignationId(){           

        }          

}

The above class is correctly structured and it has employee attributes declared. Also it has operations related to employee.

Here Employee class should have only responsibility to maintain and manage the data of employee in formations. But this class is violating the principle of Single Responsibility. How?

First, the logic of calculating the Date of Retirement is not the employee's responsibility. This might be defined under the HR class and calculate by taking employee's Date of Joining in the organization which is an attribute of Employee class. So if any change happens in the HR policies, the Employee Class does not get updated. Just because HR policies updated this has nothing to do with the Employee entity.

Second, the logic of calculating the amount of increment is a responsibility of Finance class and it calculated by taking the level or designation of the employee in the organization. So if any change happens to the financial status, the Employee class doesn’t get affected with that.

If the class has only one reason to change then it stays less fragile. More responsibilities lead to more dependencies and higher coupling. A test class for a ‘one responsibility class’ will have less test cases (branches). If a class has one purpose it will usually have less dependencies, thus less mocking and test preparing.

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. Class and module design is highly affected by SRP and it leads to a low coupled design with less and lighter dependencies.

Points to consider when you design the class.

• Define clearly what this class is going to do.
• Reduce the long procedures of the logic. Divide into multiple chunks.
• Write the code in the way that very small steps can be tested independently.

---