Living in a state of accord.

The Single Responsibility Principle (and what’s wrong with it)

Marco Cecconi - I don’t love the single responsibility principle:
The principle is arbitrary in itself. What makes one and only Reason To Change™ always, unequivocally better than two Reasons To Change™? The number one sounds great, but I’m a strong advocate of simple things and sometimes a class with more reasons to change is the simplest thing. I agree that we mustn’t do mega-classes that try to do too many different things, but why should a class have one single Reason To Change™? I flatly disagree with the statement. It’s not supported by any fact. I could say “three” reasons and be just as arbitrary.
Interesting critique of the single responsibility pattern. The quote above is perhaps one of the weaker arguments against the single responsibility pattern but it struck a nerve with me because all too often we assume that because a rule sounds good it has some validity. In reality, picking one responsibility for a class is quite arbitrary and, as the article argues, deciding what a responsibility is is even more arbitrary.
So, whilst I agree completely on the premise of not make ginormous classes, I think this principle is not at all helpful in either illustrating the concept or even identifying unequivocally problematic cases so they can be corrected. In the same way, anemic micro-classes that do little are a very complicated way of organizing a code base.
Given I’ve spent time today fixing a bug that was almost entirely caused by having too many classes with too focused responsibilities which caused the combined structure to be difficult to reason about and have unintended consequences this resonates strongly as well. Making responsibilities too fine grained is just as detrimental to the maintainability of code and somewhat counterintuitively also to it’s reusability. Reusing a single class is far simpler than having to work out how to piece together ten separate classes in the right way (hence the existence of builders which create a facade that everything is really a single unit again). I can see a lot of value in discussing things in terms of coupling and cohesion rather than responsibilities and using those concepts to find the right balance.
  • Sam Barker says:

    I tend to frame single responsibility more in terms of “do one thing well” rather than exclusively do one thing. You then largely end up in an argument about the scope of one thing, but thats probably the right argument to be having. I’d hazard a guess that the real problem you were fixing was not that the class needed multiple responsibilities but that a concept was missing, a wider responsibility the principal was applied to narrowly.

    Builders also encourage composition and thats where their real power is, they shouldn’t be patching random implementation details together.

    May 7, 2014 at 6:56 am
  • Adrian Sutton says:

    In this particular case we’d used a filter chain pattern and there were so many filters tweaking one little thing that by the time you got to the end of the chain you had no idea what the data looked like and how it reacted to changes back up at the source. It would have been much better if a number of those filters were combined to make it simpler to get a grip on the effects of that chain.

    Ultimately though you’re right, the problem with the single responsibility principle is when it is applied too narrowly and thus things get broken down too far, which is really the key point of the linked article – how far is too far and how do you know?

    May 9, 2014 at 1:44 am

Your email address will not be published. Required fields are marked *