Comparison
Separation of concernsvsSingle responsibility
Separation of concerns
you wanted to change the retry policy and had to read a HTML template to find where it was set.
Keeping distinct kinds of decision in distinct places, so that changing one kind does not require understanding the others. It is the reason business rules do not belong in a controller and formatting does not belong in a query. The payoff is not tidiness: it is that each concern can be reasoned about, tested and changed by someone who does not have to hold the rest of the system in their head at the same time.
Full entry →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 →