Single Responsibility Principle considered harmful

January 7, 2021

I’ve just come across this article, and it bummed me out quite a bit.

Theoretically, the principle per se (that is, the Single Responsibility Principle) may very well be a good one. There’s just one problem: Uncle Bob has been trying to explain it for 20 (twenty) years to no avail.

I managed to track back Martin’s process of defining this term. To sum it up:

Yet still, the article that bummed me out says "That class itself should do one thing." I feel that "one thing" is the most common interpretation of the SRP.

That could be alright, but "thing" can mean a whole lot of stuff. Is a sorting one thing? And what if a single method employs different algorithms depending on the input size? Is that still one thing, or multiple ones? And what if the code is capable of sorting arrays that exceed memory and works with the hard drive in an according manner?

You could argue day and night about the size of things. I bet the only thing software engineers over there in Heaven are busy with is arguing about how many things this or that piece of code does.

Well, to heck with the "thing." Even Uncle Bob himself is confused with the definition. In one of his articles, [quote, Uncle Bob,], he says:

We do not mix business rules with GUI code

It’s hard to argue with that. We don’t mix these things, and that’s great. However, specification changes alone often incur incur making changes to the GUI, to the rules, and to the database. That is, these things (both for one feature) should be stored in the same place.

To sum up, IMO, the SRP is a decent motto to know about. One should keep it mind when analyzing design, but it certainly isn’t that important. Naturally, it should’be embraced as a design foundation.

Here’s some more general hate towards SOLID:

And here’s Martin analyzing and replying to the consultant’s slides. Solid Relevance