Comparison
Single responsibilityvsSOLID
Single responsibility
two teams keep editing the same class for two entirely unrelated reasons and keep colliding.
The rule that a module should have one reason to change — which is a statement about people, not about code size. The useful reading is the original one: a responsibility is a stakeholder whose request causes an edit, so a class serving the finance team and the support team has two. It comes up whenever a shared file becomes a merge-conflict hotspot, which is the symptom the principle was invented to describe.
Full entry →SOLID
someone rejected the pull request citing a five-letter acronym, and only two of the five letters were actually about the problem.
Five object-design principles collected under one acronym: single responsibility, open–closed, Liskov substitution, interface segregation and dependency inversion. Taken individually they are useful heuristics with genuine failure modes to point at; taken as a checklist they are the most reliable way to talk a team into more indirection than it needs. Being able to name all five and say honestly which ones you find load-bearing is a better interview answer than reciting them.
Full entry →