“Gather together the things that change for the same reasons. Separate those things that change for different reasons.”
It’s a common misconception to simplify this as “every module should do just one thing”. That’s not quite right because it’s not the “doing” that’s the point.
Boiling your code down to the simplest possible components can lead to horribly disjointed software. It’s the reason to change that’s key rather than what it’s doing, but what defines a reason to change?
The principle is primarily about people. Those users and stakeholders that push for new features are those that drive change in your software, and it’s specifically the scope of that change that we’re looking to limit.
It’s frustrating for both users and developers when a reasonable tweak in one concern leaks into, and breaks, another. You’ll want to separate the responsibilities to avoid exactly this and to reduce the mental burden required by a developer when dealing with just one piece.
The single responsibility principle applies across the whole stack, from minute detail to high-level abstraction. It holds when building granular functions or coarse components and in determining architectural boundaries.
It may be seen under a different guise, for example, the common closure principle which itself advises that components should be deployed according to change and that any change should effect a minimal set of components (ideally one).
Much of the SRP can be seen as an answer to a development scalability problem.
Separate those areas that can change for different reasons and you can scale out your engineers without them treading on each other’s toes or scale-up teams without blocking dependencies and bottlenecks between them.
Originally published at Better Programming
Top comments (0)