SRP, A Problem

SRP, the Single Responsibility Principle, has its canonical statement as the following:

“THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.”

This is all well and good. But consider the following:

1) A class that has more than one reason to change violates SRP.

2) A class that has more than one function has more than one reason to change.

3) A class that has more than one function violates SRP.

Or:

1a) A class that has more than one reason to change violates SRP.

2a) A class that has more than one property has more than one reason to change.

3a) A class that has more than one property violates SRP.

Now, almost anyone who accepts SRP would reject 3 or 3a (there’s always some nutjob out there, so ‘almost anyone’.).

But, 1-3 and 1a-3a are valid arguments. Therefore, 2 and 2a must be rejected as false.

The problem is explaining exactly why they are false.

Why are they false?

posted on Friday, February 13, 2009 7:55 PM Print

Comments

# re: SRP, A Problem: Sergio Pereira; 2/13/2009 8:33 PM; When I explain SRP to other developers I try to focus not only on the S, but also on the R. Defining what you mean by responsibility and what a given class' responsibility is will not necessarily force you to have one-method classes.
To use a simple example, let's assume we have a basic Calculator class. If you consider Addition, Subtraction, Division and Multiplication big enough concerns that deserve their own class, then a Calculator class that implements these operations directly would violate SRP. On the other hand, if you just consider the four operations obvious parts of what a calculator is expected to do, then it makes total sense that the calculator exposes those four functions without doing more than its responsibility: perform basic calculations. On the other hand (that's my 3rd hand for anyone keeping track) you'd have to work hard to convince me that adding a ChangeTvChannel function doesn't violate SRP.

# re: SRP, A Problem: jdn; 2/13/2009 8:42 PM; But that is part of the point.

You can 'solve' the problem by redefining what 'responsibility' means, or by what 'reason' means.

But then SRP just becomes a principle that can be redefined to meet, or not meet, anything.

# re: SRP, A Problem: Sergio Pereira; 2/13/2009 10:43 PM; That's why it's a principle, not a formula. Your experience will be an important factor when drawing the line that bounds the responsibility. You'll have to consider, among other things, the chances of a given function changing ("isolate what changes".) I don't think we will many recipe books for applying these types of principles.
You're right when you say that one can redefine 'responsibility', but I'd argue that changing it too much incurs a change in the class name (e.g. CalculatorTvRemoteCombo class, in my previous example)

# re: SRP, A Problem: Casey; 2/14/2009 1:50 AM; Sergio got it - a Responsibility is not 1 method or 1 property, it is a coherent group of methods and properties

# re: SRP, A Problem: jdn; 2/14/2009 11:11 AM; Define what makes a particular group of methods or properties coherent.

And without bringing in terms that are synonymous with 'reason' or 'responsibility'.

# re: SRP, A Problem: jdn; 2/14/2009 12:42 PM; "That's why it's a principle, not a formula. Your experience will be an important factor when drawing the line.."

But how? If I can't define the principle in anything but vague terms, how do I know when I am following it properly or not? I can ask someone else, but how do *they* know when they are following it properly or not?

Sprinkling Active Record attributes on my class doesn't make me want to change the class name. But one could point to that as a violation of SRP.

Uncle Bob's article itself ends up with an SRP violation at the end, but one that is, I guess, okay. Or okay enough.

So I can't really define the principle except for outlier cases, and it is, in fact, okay to violate it in certain cases.

Then why should I care about it?

# re: SRP, A Problem: Troy Tuttle; 2/15/2009 4:56 PM; Great questions. It's hard to come up with adequate answers when answering from an indignant absolutist perspective (like so many of the blog posts the last week).

As you point out from your questions, it may be less about being a principle as it is about being a goal.

# re: SRP, A Problem: jdn; 2/15/2009 6:43 PM; Troy:

That's probably the best way to look at it, and might be better formulated as a negative "classes should not have more reasons to change than necessary" or something, although the same similar problems remain.

# re: SRP, A Problem: Brian; 2/17/2009 5:20 PM; Somebody explain without using 'simple' calculator classes or other first day of CS examples. First thing I always see are simple examples for simple solutions; unfortunately the real world has more than calculators, email services, loggers, spell checkers, and text editors in it.