2

Two common phrasings for the Single Responsibility Principle (SRP) are "each module should be responsible for a single feature or functionality in a system", and "each module should have only one reason to change".

My questions is: is this something that we should absolutely strive for in every class of a system, or should it be relaxed when we combine lower-level modules to compose the more abstract modules?

At the extreme case, the top-level module in a system will be responsible for the entire gamut of system functions, so it looks like it may not be possible to respect the SRP in this kind of module.

3

If the top-level module delegates all of its functionality to submodules and only glues them together, that leaves it with one responsibility ("gluing the other modules together") and one reason to change ("something fundamental changed about the architecture that requires a change in the submodule set"). Every other change to the program should not cause a change to the top-level module, just the appropriate submodules.

The SRP is an ideal. Like all ideals, you have to weigh the cost of pursuing it against the benefits it brings.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.