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.


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

1 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.

  • May I also ask whether my assumption in my first question is correct? Jul 4, 2012 at 19:29
  • 1
    I would say so. I mean, the fact that two classes/responsibilities may change at the same time for the foreseeable future doesn't mean that will always be true. Though, I would offer the caveat that it would be easier to comment on specific examples. Two classes that are always changing at the same time only might be a design smell. Jul 4, 2012 at 19:34
  • "Two classes that are always changing at the same time only might be a design smell" They would be a design smell even if their responsibilities are vastly different ( ie non-related )? Jul 4, 2012 at 20:07
  • 2
    I mean, I can only say so much when speaking in hypotheticals, but yes, something seems fishy about two vastly different classes always needing to change at exactly the same time, like it would seem fishy if you always needed to replace the tailpipe of a car when you replaced the steering wheel. There may be a reasonable explanation for it in your situation, but that's why it's a design 'smell' and not necessarily a problem. It just seems... curious. Jul 4, 2012 at 20:10
  • thanx much for your help Jul 5, 2012 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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