Something confusing about Single Responsibility Principle

Question

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

Answer 1

I imagine that it's just a matter of how general those responsibilities are. For instance, you might have a library/assembly called DataAccessLayer, whose single responsibility is fetching data from persistence. Within that, you might have a class CustomerDao, whose single responsibility is fetching customers from persistence.

I guess one could make a highly semantic argument that this compositional nature means that the assembly has as many responsibilities as DAOs, but I think that's really more of a nitpick than a reasonable argument against the concept being conveyed with SRP.