So have a lot of other people; my understanding of it accords with much writing I’ve seen about the principle on the web, and elsewhere. For example, in Michael Feathers’ “Working Effectively with Legacy Code”:
Every class should have a single responsibility: It should have a single purpose in the system, and there should be only one reason to change it.
Michael Feathers, Working Effectively with Legacy Code (p.246)
I came to question that understanding today when I read Parnas’s article On the Criteria to be Used in Decomposing Systems into Modules. His top criterion is decision hiding: everywhere you make a choice about the system implementation, put that choice into a module with an interface that doesn’t expose the choice made.
If you combine that principle with my incorrect SRP (“one reason to change per module”), you get the absurd situation that each module may contain only one change point. In other words, each bit of software architecture information must exist in a separate module.
So, I went back to my understanding of the SRP. I found that it was flawed, and that the person who coined the phrase Single Responsibility Principle (Robert Martin) even said as much. He said it a long time ago, but years after the incorrect interpretation had got its shoes on and run twice around the world.
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.
Robert Martin, The Single Responsibility Principle
So the principle is that the module’s behaviour is the responsibility of a single actor. It’s not that the module has a single reason to change, but that a single entity will request the changes. This is much easier to resolve alongside Parnas’ version of modularity.
This isn’t some new deep revelation or hidden insight, by the way. That post by Martin is referenced on the wikipedia entry for SRP, which states the true (well, the as-given) definition of the principle. The fact that I and so many others can hold a completely different view, for so long, in the face of such obvious contradictory evidence, tells us something about knowledge transfer in software engineering that we probably ought to attend to.
Accurate knowledge transfer seems to be a difficult task. Or maybe not difficult, just ignored.
You’d think that people whose occupation is unambiguously specifying data manipulation operations might find some way to do it though.
I’m having trouble understanding the new meaning. In this new (to me!) meaning more like:
1. Fred Brooks’s “surgeon” or a Directly Responsible individual should have ownership over the design of an object
2. Conways Law for Objects. Objects should map to your specific organization’s functions.
3. The heuristic for good design is to think of the objects like a bureaucracy or pre-automation factory process and be like “an object should be about the same scope as a human performing the work; in the middle of the spectrum of burnout on one end and redundant/layoffable at the other end.
As I understand it more like your second option. The logic of the module should be the responsibility of one business function, so that you don’t have to resolve political battles to make changes.
This reminds me of Conway’s corollary: the most efficient way to make software is for the architecture to match your organization.
I may be wrong here, it’s been a while since I read both books, but I think Michael Feathers’ classes do not necessarily equal Robert Martin’s modules. From my understanding, Robert’s modules may encompass software entities in general, from a single class up to a system whereas Michael’s classes really do mean a single class in the OOP sense.
Then statements that are true about general modularity must be true about classes specifically, right?
Same thing happened with Hungarian notation, back in the day. https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/