The Many Faces of the Single Responsibility Principle

SRP formulas

First off, let’s see the most popular formula—albeit a wrong one:

Well, the principle per se certainly exists. It’s one of the principles guiding Linux philosophy. However, Martin himself says in his "Clean Architecture" that it has nothing to do with SRP:

Martin himself has provided three formulas for SRP:

To understand what these three have in common, I had to give three reads to every single piece Martin has ever written on SRP. You’ll save yourself a day or two and get the same answer in 15 minutes if you make it to the end of this post.

Let’s start with looking at how Uncle Bob has been explaining SRP for the last 20 years.

SRP explanations

Agile software development Principles Patterns and Practices, 2003

The SRP makes it first appearance in the Agile software development Principles Patterns and Practices. In this book, Martin explains it with separating the code based on what it’s responsible for in the system:

Clean Code, 2008

Martin keeps explaining the basic idea of SRP as separating the code based on its responsibilitiesZZ in his Clean Code:

public class SuperDashboard extends JFrame implements MetaDataUser {
    public Component getLastFocusedComponent()
    public void setLastFocused(Component lastFocused)
    public int getMajorVersionNumber()
    public int getMinorVersionNumber()
    public int getBuildNumber();
}

The Clean Coder, 2011

Next, in his The Clean Coder, Uncle Bob explains SRP with separating implementation concerns (that us, the GUI and the business rules):

The Single Responsibility Principle, 2014

In his next piece on SRP, Uncle Bob explicitly uses the "separation of concerns" term:

Here, we have the first time Martin gives SRP this brand new definition:

Here, he’s talking about separating code by people behind writing it.

Clean Architecture, 2018

This explanation received its final form in four years, in Clean Architecture:

Here, an actor is a group of stakeholders—that is, people in some way or another related to the app and/or engaged in developing it—who share the same needs and wants.

The sixth SRP formula

I think the sixth—mine—SRP formula is far more clear:

This formula is based around a quite specific concept of a requirement. I think there are much less conflicting interpretantions to the word "requirement" than there are to the word "actor." "Actor" per se isn’t the best word, as it’s usually understood as "the program’s user"—a definition popularized by the UML.

In my formula, it’s clear why data storage modules should be separated from data presentation modules. The former are specified by the DBA, and the latter by the UX designer. It’s also clear why you should separate the modules responsible for implementing the CFO and COO responsibilities. The requirements for these are defined by different people from different departments.

This formula isn’t perfect as well, though. First, infrastructure modules will be fulfilling at least two requirements, i.e. the functional and the quality ones. Second, I’ve never seen a project that would have the functional and the non-functional requirements, stakeholder list, and stakeholder relations all clearly written out.

Neither this SRP formula nor any other one doesn’t provide software engineers with a guide on the nuts and bolts of how they should be implementing the principle in their everyday work. Perhaps it would be more useful to break SRP down into multiple down-to-earth recommendations? For example:

These recommendations don’t require extensive planning ahead with defining the stakeholders and the requirements. It’s also easy to see whether you’re following these recommendations when writing your code.

These are much easier to use in day-to-day work for wider circles of software engineers. They would also result in a system that’s reliable and easy to maintain.

I have one more recommendation apart from those listed above. You should separate the "default library" (the domain) and the "scripts" (functions) of the application. This is dicussed by both Martin in his Clean Architecture as the separation of entities and interactors and Evans in his DDD as the separation of application and domain services. Nether they nor I can provide any objective criteria that could allow to see whether the code you’re writing adheres to this recommendation. Therefore, I’m not listing it as a simple and clear one.

Here we go 'round the mulberry bush

SOLID relevance, 2020

The constant change of SRP formulas and interpretantions could be explained with Martin’s own understanding of SRP changing and evolving. At first, SRP meant for him that we should separate the code by its responsibilities. Then it occurred to him that the code should also be separated by implementation concerns. Finally, Uncle Bob combined both under "people-based" code decomposition.

This was an excellent explanation of SRP history, all the way until Martin wrote his last post on SRP. In that post, he went back to concerns-based code decomposition:

If we take a step back and look at SRP explanation history, it’ll become clear that Uncle Bob keeps jumping back and forth between these code decomposition criteria:

Responsibilities-based decomposition and implementation concerns-based decomposition aren’t two ways of laying out the same principle. These are two different principles that lead to different results.

We need new principles

To sum things up:

Even though SRP is the most questionable SOLID principle, the other four have their fair share of problems and conflicting readings as well. Therefore, I don’t think that SOLID as it is can be a good system design guideline.

Yet still, the SOLID contains quite a lot of good and useful ideas. That’s why I’m not calling for it to be abolished altogether — I’m suggesting for it to be reinstated. We should pick out the relevant ideas it contains, make these more specific, and supplement them with best-practice examples. Naturally, everything that has now lost its relevance should be deprecated.

Here’s the most important part: we shouldn’t pigeonhole ourselves by only using those principles whose first letters can form up a pretty acronym.