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.

Single Responsibility Principle is based on high cohesion principle. The difference between the two is that highly cohesive classes feature a set of responsibilities that are strongly related, while classes adhering to SRP have just one responsibility.

But how do we determine whether particular class features a set of responsibilities and is thus just highly cohesive, or whether it has only one responsibility and is thus adhering to SRP? Namely, isn't it more or less subjective, since some may find class very granular (and as such will consider a class as adhering to SRP), while others may find it not granular enough?

share|improve this question

migrated from stackoverflow.com Jun 28 '12 at 18:22

This question came from our site for professional and enthusiast programmers.

4 Answers 4

up vote 6 down vote accepted

Why yes it is very subjective, and it is the subject of many heated, red-faced debates programmers get into.

There's not really any one answer, and the answer may change as your software becomes more complex. What was once a single well-defined task may eventually become multiple poorly-defined tasks. That's always the rub too. How do you choose the proper way to divide a program up into tasks?

About the only advice I can give is this: use your (and your coworkers') best judgement. And remember that mistakes can (usually) be corrected if you catch them soon enough.

share|improve this answer
    
I apologize for the late reply. Thank you all for your kind help –  user1483278 Jul 4 '12 at 17:22

Bob Martin (Uncle Bob), who originated the SOLID principles of which SRP is the first, says about this (I am paraphrasing, can't recall the actual words):

A class should only have one reason to change

If it has more than one reason, it does not adhere to SRP.

share|improve this answer
1  
That's just repeating the definition really, but actually adhering to srp is still pretty subjective. –  Andy Mar 12 at 21:37

I can give you several rules of thumb.

  • How easy is it to name the class? If a class is difficult to name, it is probably doing too much.
  • How many public methods does the class have? 7+/-2 is a good rule of thumb. If the class has more than that, you should think about splitting it into several classes.
  • Are there cohesive groups of public methods used in separate contexts?
  • How many private methods or data members are there? If the class has a complex internal structure, you probably should refactor it so that the internals are packaged into separate smaller classes.
  • And the easiest rule of thumb: how big is the class? If you have a C++ header file containing a single class that is more than a couple of hundred lines long, you should probably split it up.
share|improve this answer
    
Regarding your second point, see uxmyths.com/post/931925744/… –  Cameron Martin Mar 19 at 12:59

OO says that classes are a grouping of data a functionality. This definition leaves plenty of room for subjective interpretation.

We do know that classes should be clearly and easily defined. But, in order to define such a class, we have to have a clear notion of how a class fits into the overall design. Without waterfall type requirements which, paradoxically, are considered an anti-pattern...this is difficult to achieve.

We can implement a class design with an architecture that works in most cases, like MVC. In MVC applications we only assume to have data, a user interface and a requirement for the two to communicate.

With a basic architecture, it's easier to identify cases where single responsibility rules are being broken. E.G. Passing an instance of a User Control to a Modal.

share|improve this answer

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.