The Single Responsibility Principle (SRP) states that a given module or component should have a single responsibility. Often, the SRP is described alternatively as “having only a single reason to change”, in accordance with Dave Parnas’s paper On the Criteria to be Used in Decomposing Systems into Modules:
We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.
Robert Martin provides another wording for the SRP:
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
The SRP is a metric that can be used to judge the cohesion and coupling of a given module or component. You can easily identify components or modules that do not embody the SRP by looking for mixed metaphors.
The SRP is the “S” in the acronym SOLID.
Related Concepts
- The SRP is an application of Separation of Concerns taken to the extreme.
- High cohesion and low coupling is a realization of the SRP. As Robert Martin says:
We want to increase the cohesion between things that change for the same reasons, and we want to decrease the coupling between those things that change for different reasons.
- Robert Martin said that he came up with the SRP to combine Parnas’s idea of Information Hiding and Dijkstra’s idea of Separation of Concerns
References
- SOLID
- The Single Responsibility Principle (paper) by Robert Martin
- Design Principles and Design Patterns by Robert Martin
- The Single Responsibility Principle by Robert Martin
And this gets to the crux of the Single Responsibility Principle. This principle is about people.
When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function. You want to isolate your modules from the complexities of the organization as a whole, and design your systems such that each module is responsible (responds to) the needs of just that one business function.
However, as you think about this principle, remember that the reasons for change are people. It is people who request changes. And you don’t want to confuse those people, or yourself, by mixing together the code that many different people care about for different reasons.
- Paper: On the Criteria to Be Used in Decomposing Systems into Modules by David Parnas
- Patterns in the Machine : A Software Engineering Guide to Embedded Development by John Taylor and Wayne Taylor
Remember that layers are your friends when it comes to unit testing, especially when implementing automated unit testing. It is also the key to decoupling code and preparing your software for future reuse. The Single Responsibility Principle is a tactical best practice, but it enables strategic best practices such as unit testing and platform-independent code.
- One Responsibility Rule | C2 Wiki
From BertrandMeyer‘s ObjectOrientedSoftwareConstruction, there was the statement (quoting from memory):
A class has a single responsibility: it does it all, does it well, and does it only.
[…]
One of the criteria I use is to try to describe a class in 25 words or less, and not to use “and” or “or”. If I can’t do this, then I may actually have more than one class.
« Back to Glossary Index