Single Responsibility Principle Interpreted from a New Viewpoint (从一个新的视点解读单一职责原则)
Every software developer today who’re developing the software using the Object-Oriented Design technology should get familiar with the SOLID design principles which simply include:
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
The Single Responsibility Principle or SRP is the first important principle that states that a class should have only one responsibility or a class should have only one reason to change. Basically, this principle applies to the class design, but recently a design discussion on a specific topic brought up a very interesting question on the SRP, the question is could this principle also be applied to the design of a software component which is typically an aggregation of a set of classes? If it is appliable, how the principle could be interpreted under the context of a software component?
Before moving forward, a clarification or definition of the ‘responsibility’ and the associated word ‘role’ would be helpful.
The Responsibility is defined as “a charge assigned to a unique actor to signify its accountabilities concerning a unique business task”.
A role is defined as “a set of connected behaviors, rights, obligations, beliefs, and norms as conceptualized by people in a social situation”, or “The function assumed or part played by a person or thing in a particular situation”.
From those definitions, it could be derived that every role has different responsibilities attached to it, and the role could be viewed as the aggregation or abstract description of all the associated responsibilities.
Take the software development as an example, the front-end engineer is a role, and in this role, the person will be responsible for the overall development tasks related to front end development. But the responsible description here is a description of the role or a very high-level description about the responsibility. The actual responsibilities may include: write the presentation code using HTML, JS, CSS etc, write unit test code for those and ensure the unit test coverage, integrate with the backend code bases, fix all the bugs related to the front-end code, etc, this can be modeled as below diagram:
And for a software development manager who may manage a team of front-end engineers, back-end engineers and test engineers, the role of that person will be software development manager who is responsible for software product development, but the actual responsibilities would include the front-end development, back-end development, test and integration, and software product release. But the front-end development responsibility will be delegated to front-end engineers, back-end development responsibility to back-end engineers, and software release to configuration and release engineers.
This could be modeled as below diagram:
The front-end development responsibility for the SW manager role may seems to be “big” (or high level), while the responsibility for the front-end engineer role would be very “small” (or low level, detailed).
From this example, we can come to a conclusion that the software manager is a single role, it has multiple responsibilities and those responsibilities could be delegated to the other roles in the software development team.
To describe the same in a more abstract approach, we could get below diagram:
- A software component which is the aggregation of a set of classes would have single role, but multiple responsibilities;
- Each individual responsibility could be assigned to a class;
- Each class should have a single responsibility;
Therefore, the conclusion here is the SRP could be applied to software component composed of multiple classes, but the “R” in this context should be interpreted as “role” instead of “responsibility”.