Challenging the Single-Responsibility Principle

There’s some art to identifying what the single responsibility should be at a particular abstraction layer and use that. It’s not meant to be taken literally. there’s an excellent talk in cppcon on this https://youtu.be/Ntraj80qN2k?si=-jsMAccDMKMFQPo8

> no matter how small a component already is, the single-responsibility principle can still be applied: every line of code can be assigned its own responsibility

The definition of SRP is to have each class (or module) to have a single reason to change. I don't see how that has anything to do with having each line be assigned a responsibility. If the line changes for the same reasons as it surrounding lines, then, they are part of the same component (to use the author's wording). My guess is that the principle is being taken literally from its name/acronym.

> Unfortunately, it is often used as a killer argument to chop up a software system beyond all recognition.

In all my years, all the companies and codebases I have ever seen, I have literally never seen a system chopped up this way by the SRP. The number of monoliths, though, are uncountable. The number of modules where some function is trying to juggle 8 different tasks, all conflicting … this is the constant state of affairs of actual code in the industry.

The SRP is not about chopping code up into (literal!) single lines; as I (and many others — this isn't some unique thought of mine) the SRP is about semantic, not syntactic — responsibility. It is fine, within the SRP, to have syntactically identical functions, if they serve semantically different purposes. "Are these two functions/sections of code bound to be the same by the law of physics?" If "no" … it's fine if there's a little copy paste here and there. Copy B's requirements might change down the line, and coalescing them into a single copy would be pain later down the line.

Drink with moderation.

> The big advantage of a group 0 component is that you can consume it within components from any other group (like blood type 0 (sic) can be received by any other type).

sigh. The blood type is "type O". Though, I do like the A/T separation, and yeah, generic-ish things become away of specific logic is usually a smell. (Though I'd love, like, some thoughtful reasoning. It resonates with me … but maybe a "why?".)

Worth noting that in each well defined domain area, this can be replied recursively.

I.e. within the domain are the (O) basic structures, relations and operations.

Then (T) practical supporting algorithms, tuned for performance in specific cases, serialize, visualize, or whatever.

Then (A) the code that uses O & A to implement the details of specific solutions or manage specific processes.

Wherever there is a well defined broad class of problems with shared structure, this approach has merit.

• Minimize AT -> A, T, O or X.

• Minimize A -> T, O or X.

• Minimize T -> O or X.

• Minimize O -> X.

Where Blood Type X is... Well its just code that doesn't need to exist. Now all possible code has a blood type. And highest productivity is to increase code in X.

As they say, less (OTA), is more! (X)

KISS my DRY SOLID goodbye.

"I've seen many teams building distributed monoliths and spaghetti code in pursuit of the SRP."

I've worked with probably 6 or 7 different "microservice" based systems at this point, essentially all of them are just distributed monoliths. I don't think I've met a single person at my company who actually know what the hell a "microservice" is.

Much like Unbreakable, I felt like this ended just as it was starting to get good.