Something confusing about Single Responsibility Principle
- by user1483278
1)
In fact if two responsibilities are always expected to change at the
same time you arguably should not separate them into different classes
as this would lead, to quote Martin, to a "smell of Needless
Complexity". The same is the case for responsibilities that never
change - the behavior is invariant, and there is no need to split it.
I assume even if non-related responsibilities are always expected to change for the same reason ( or if they never change ), we still shouldn't put them in the same class, since this would still violate high cohesion principle?
2)
I've found two quite different definitions for SRP:
Single Responsibility Principle says that a subsystem, module, class,
or even a function, should not have more than one reason to change.
and
There should never be more than one reason for a class to change
Doesn't the latter definition narrow SRP to a class level? If so, isn't first quote wrong by claiming that SRP can also be applied at subsystem, module and function levels?
thank you
