You might be familiar with the Single Responsibility Principle (SRP), one of the SOLID principles coined by author Robert C. Martin. The SRP states that “A module should be responsible to one, and only one, actor”, where actor is defined as a group of people (e.g., users or stakeholders) who require a certain change.
At this point you might be surprised: Wasn’t there something about “one reason to change”? In earlier writings Robert C. Martin used that wording, but he later regretted it because of how often it was misinterpreted, so he reformulated it in later books and blog articles. It’s not a different interpretation by another person, just a clarification by the same author.
Whichever wording you prefer, the intention is the same: The SRP tries to increase cohesion, i.e., put closely together the things that are likely to change together (and only those), while minimizing the risk of breaking functionality through seemingly unrelated code changes.
Misinterpretations
Perhaps the most common misunderstanding is that a responsibility is something that the module does. And if that were the case, it would mean that a class should only do one thing. Unfortunately and frustratingly, this is probably the most common definition of the SRP that I hear or read on the internet!
Robert C. Martin has this to say about the SRP’s unfortunate choice of name:
“Of all the SOLID principles, the Single Responsibility Principle (SRP) might be the least well understood. That’s likely because it has a particularly inappropriate name. It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing.”
Robert C. Martin
Clean Architecture (p. 62), Pearson Education (Kindle Edition)
I also regularly hear or read claims along the lines of “the SRP can also be applied to methods: A method should only do one thing. And to architecture layers: A layer should have one responsibility.”
These claims are problematic for two reasons:
- They indicate (and worse, they propagate) a false understanding of the principle. The SRP is not concerned with how many things a module is responsible for doing but for whom it does them.
- The SRP does explicitly not apply to these situations. They are addressed by other principles.
The Single Responsibility Principle is explicitly not about functions doing one thing, but only about modules. That is not a matter of interpretation, it is explicitly stated and clarified by the author who coined the SRP:
“Make no mistake, there is a principle like that. A function should do one, and only one, thing. […] But it is not one of the SOLID principles—it is not the SRP.”
Robert C. Martin
Clean Architecture (p. 62), Pearson Education (Kindle Edition)
Secondly, it can not be extended to higher levels, like architectural layers; there are separate principles for that, too, and explicitly distinguished by Robert C. Martin.
Principles for higher levels: SoC and CCP
Separating code into different architectural layers (and similar kinds of separation) is known as Separation of Concerns (SoC). These concerns are not “responsibilities” in the spirit of the SRP. It’s a common mistake to extend the SRP to a much wider context and thus “reinvent” SoC, but by doing that we actually lose meaning and precision. The SRP was coined as a combination of concepts like Separation of Concerns, coupling, and cohesion, specifically for modules (clarified by the author as meaning classes in most programming languages), to address a very specific and rather narrow set of common design problems.
He did actually coin another principle that he bases on the SRP and that applies to the component level: The Common Closure Principle (CCP).
“Just as the SRP says that a class should not contain multiples [sic] reasons to change, so the Common Closure Principle (CCP) says that a component should not have multiple reasons to change.”
Robert C. Martin
Clean Architecture (p. 106), Pearson Education (Kindle Edition)
Both principles exist because they are not the same. They may be similar, but they apply to different contexts.
Conclusion
The SRP and SoC both exist. They may sound similar and are related, so I can’t blame anyone for getting them mixed up, but they are not the same. The SRP applies specifically to modules, and the meaning of “responsibility” is often misunderstood.
We can reduce the risk of misinterpretations by looking into the original sources. A lot of meaning is lost by propagating information only by hearsay and adding our own flavors of interpretation to them. Instead of trying to redefine existing principles to encompass more situations, thus losing meaning and precision, we should learn about other existing principles that already address those.
Raimund Krämer 