Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

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.

share|improve this answer
    
May I also ask whether my assumption in my first question is correct? –  user1483278 Jul 4 '12 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. –  Erik Dietrich Jul 4 '12 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 )? –  user1483278 Jul 4 '12 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. –  Erik Dietrich Jul 4 '12 at 20:10
    
thanx much for your help –  user1483278 Jul 5 '12 at 20:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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