Introduction

The Single Responsibility Principle is the S in SOLID, it is defined as:

Single Responsibility Principle(SRP) - A class should have one, and only one, reason to change.

The SRP is at many times misinterpreted as a method should do one thing and one thing only, this is a wrong definition of the SRP.
When we think about methods or modules having single responsibility we can consider it is part of a clean code concept and not how the SRP should be addressed.

Instead software developers needs to think about the users or group of users that will make use of a certain classes as seen in the following sections.

Problem Definition

When applying the SRP software developers need to take into consideration the actors that will make use of the developed module. Consider Figure 1 and its actors.

Figure 1 - Student class diagram and its actors

There are three public methods contained in the student class:

• The CalculateGradePointAverage is mostly used by the students.
• The GetAbsence is mostly used by the parent to check the status of the student absence.
• The GetRanking is typically used by the school to print the student ranking compared to his peers in his report card.

At this point all of these methods are coupled into a single Student class that is used by different groups of users.

Figure 2 - Shared private method

Figure 2 displays that the calculateGradeAverage private method is used by the CalculateGradePointAverage and GetRanking. The developer considered creating this private method to prevent code duplication.

Lets now consider business changes in the school policies that will affect the ranking system logic. In this case changes to the calculateGradeAverage method is necessary to comply with the rules, however the changes to the calculateGradeAverage method also introduced changes to the CalculateGradePointAverage that should not have changed.

Problem Resolution

This is where architectural decisions can come into place, since there may be different solutions to the same problem. Creating a separate class for each user is one solution as displayed in Figure 3. Also a common model between these classes could reduce code duplication.

Figure 3 - Different classes isolated from each other

Going Deeper

At this point we now have three classes that should be instantiated, if these classes are used in the same scope a facade could be introduced as displayed in Figure 4.

Figure 4 - Facade pattern

The Student Facade class does not implement much code since it redirects to the classes responsible for each operation.

Conclusion

The SRP is connected with methods and classes, when designing classes for different users or groups of users it is crucial to take into account the context and classes that are created to solve the users need and how these changes might impact code maintenance and business growth.

References

1. Martin, Robert C. Clean Architecture