1 minute read

The Single Reponsibility Principle (SRP) is commonly misunderstood1. Often you might hear explanations like “a class should do only one thing”, sometimes even extended to methods.

Here’s a heuristic that I think might help:

  • If you’re tempted to break up a class into multiple classes “because the SRP says so”, it’s probably for the wrong reasons and based on a common misconception.
  • If, on the other hand, you want to extract something out from a class because “it feels like it doesn’t belong here”, you’re probably closer to the intended meaning of the SRP. Bonus points if you can describe a more concrete reason for *why *splitting it up feels right, *without *referring to the SRP as the root cause.

This may not only lead to less-bad code, but as a side effect also to a better understanding of how the SRP was intended by its author. It tries to increase *cohesion rather than split things up as much as possible, and it helps us *justify breaking cohesion in order to balance cohesion and coupling. Thus in a way it also prevents us from overdoing the similarly often misunderstood DRY principle.

Pro tip: Instead of only searching for explanations of the SRP and similar concepts, we can try additionally searching for common misunderstandings and comparing them with our own. We might sometimes even find sources from the original authors explaining how and why a concept is commonly misunderstood.


  1. I’ve written before about the common misunderstanding and how to correct it. This post focuses on what to do when we find out that we’ve fallen into the same trap, and how we can prevent similar misconceptions in the first place by questioning our assumptions.