Single Responsibility Principle (SRP) – what’s wrong with it?

Disclaimer. I don’t know why, but many programmers are not critical enough about what “academicians” write about in books. On the hub, even if we discard the obvious haters, a number of popular, but incorrect, opinions also remain. Therefore, I often write and film on my channel on topics that are not perceived so clearly, but when they seriously listen to what I’m talking about, there are not so many serious arguments. But those who look at these issues superficially hate. Please don’t want to go deep just pass by. And of course, I understand that a neutral plush consideration is perceived with more sympathy, but alas, it often leads to harmful consequences in the field of AI … so they already write about SOLID in the conditions of the reception about work, which can cause nothing but a smile. Do not do it this way ..

With the next series of video clips, I urge you to think with your own head and get acquainted with the sources, in order to encourage you to do this, I present another series of 3 parts on the topic “Single Responsibility Principle” – below you will find out what is wrong with it.

We consider B. Martin’s book “Rapid Program Development”, specifically trying to understand how he and B. Kos programmed the game “Bowling” (one of the chapters is devoted to this). We do this in order to understand first the context of how it arose and who is the person who proposed the principle of single responsibility. We understand that this is an “inveterate structurist” who tried himself in the role of an OOP `shnik, a detailed examination of the “bowling game” unambiguously leads us to this understanding. It is confirmed that this (single responsibility) principle allows to smooth out the effects a little when programming in an object-oriented language by those who think exclusively structurally. It turns out a little better than completely in the structural (procedural) paradigm, but still far, if you think immediately in terms of OOP. An example is shown of how to program a “bowling game” initially using OOP, and it becomes clear how it differs.

In general, an application is made to continue this review in the next video, because. the single responsibility principle, which proposes how and when to improve the quality of the source code – “class cohesion”, is in conflict and does this at the expense of another quality of the source code “class completeness”.

Second part.

We directly consider the principle of single responsibility and its connection with the roles and completeness of the class. We come to the conclusion that the principle is not clearly formulated and has few examples and cases for its application, it is rather a criterion for when it makes sense to divide the class into parts depending on the roles. And often the examples given do not stand up to any criticism.

The third part.

An example of how to replace the single responsibility principle in order to solve the issue of relatedness of classes instead of dividing a class by roles. Summing up and proposal to replace the single responsibility principle with another one