Single-Responsibility Principle (SRP)
Keep in mind: It’s a heuristic, after all, not a law with strict rules.
[The code of a] class or module should have one, and only one, reason to change.
(Robert C. Martin (2009): Clean Code. A Handbook of Agile Software Craftsmanship, Upper Saddle River: Prentice Hall. Page 138)
- SRP is about change; a ‘responsibility’ is not an essential property.
- Change is about the code.
- Locality of information is a structural means to achieve this.
Focus on Change of Code
Instead of applying SRP to figure out a responsibility of a design element/module, as if it was an essential property of naive ontology, consider a process-based approach: how many reasons does a thing have to change?
A good object does not need to change when the database is replaced and the view has to look different. Persistence and display are two common responsibilities that are easy to spot. On the method level, it’s harder for me to pin down:
- is the signature/the list of parameters the only valid reason to change?
- are business concerns and app requirements a reason to change the method?
In the end, business requirements can affect all levels of abstraction.
Object changes result in method changes.