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.

I'm having a difficult time understanding the Single Responsibility Principle.

What should I look for to evaluate the various sources of information on the matter?
What should I look for in examples explaining the principle?

share|improve this question

closed as not a real question by gnat, MainMa, Yusubov, GlenH7, Thomas Owens Oct 27 '12 at 16:27

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Isn't that more of an Object Thinking principle, than an Agile one? –  Matt Ellen Feb 15 '11 at 22:23
    
This question should either be deleted, or be rephrased so it isn't just asking for a link to a tutorial. –  Kazark Oct 26 '12 at 18:02

2 Answers 2

Pluralsight has a course Principles of Object Oriented Design that covers SRP as the first topic in about 12 minutes. I believe you get a couple of hours of video for free, after that you need a subscription.

share|improve this answer

SRP is a fairly straight-forward principle.

the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

-- http://en.wikipedia.org/wiki/Single_responsibility_principle

A class should have one, and only one, reason to change.

-- http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Often, I find the second quote more applicable. I try to envision what my class does. What logic does it contain, or what external (to the class) services might it depend on.

I try to think about what might change, and how might this cause my class to change. Are there multiple things that could change and affect my class? That is a code smell (but not always reason enough to split a class).

Also, while I'm thinking along these lines, I look for cases where several classes will need to change if one other thing changes (logic, and external service, etc.). This too is a code smell.

Often, though, I have small groups of tightly coupled classes that coordinate or interact to perform a single function or service. If the changes occur across this set of tightly coupled classes, I find that ok. But if a change in, say, an external service requires changes in multiple classes in different areas of my application, that is a stinkier code smell.

share|improve this answer