Single Responsibility Principle. Not as simple as it sounds.

Single responsibility principle, the same principle of uniform responsibility,

He is the principle of uniform variability - an extremely slippery guy for understanding and such a nervous question at a programmer's interview.

The first serious acquaintance with this principle took place for me at the beginning of the first course, when young and green people were taken to the forest to make students-real students from the larvae.

In the forest, we were divided into groups of 8-9 people each and organized a competition - which group would drink a bottle of vodka faster, provided that the first person from the group pours vodka into a glass, drinks the second, and bites the third. The unit that performed its operation gets to the end of the group queue.

The case when the queue size was a multiple of three, and was a good implementation of the SRP.

Definition 1. Single responsibility.

The formal definition of the principle of common responsibility (SRP) says that each object has its own responsibility and reason for existence and this responsibility is only one.

Consider a booze object ( tippler ).

To fulfill the SRP principle, we will divide the duties into three:

• One pours ( PourOperation )
• One Drink ( DrinkUpOperation )
• One Bites ( TakeBiteOperation )

Each of the participants in the process is responsible for one component of the process, that is, it has one atomic responsibility - to drink, pour or snack.

Drinking, in turn, is a facade for these operations:

lass Tippler { //... void Act(){ _pourOperation.Do() //  _drinkUpOperation.Do() //  _takeBiteOperation.Do() //  } } 

What for?

A human programmer writes code for a monkey man, and a monkey man is inconsiderate, stupid, and always in a hurry somewhere. He can hold and understand about 3 - 7 terms at a time.

In the case of drinking these three terms. However, if we write the code of one sheet, then there will be hands, glasses, massacres and endless debates about politics. And all this will be in the body of one method. I am sure you have seen such code in your practice. Not the most humane test for the psyche.

On the other hand, the ape-man is sharpened to model real-world objects in his head. In his imagination he can push them, assemble new objects from them and disassemble them in the same way. Imagine an old car model. In your imagination, you can open the door, unscrew the door trim and see the window regulator mechanisms, inside which there will be gears. But you can not see all the components of the machine at the same time, in one "listing". At least "ape-man" can not.

Therefore, human programmers decompose complex mechanisms into a set of less complex and working elements. However, it is possible to decompose in different ways: in many old machines, the air duct goes out the door, and in modern ones, the lock electronics fails to prevent the engine from starting, which delivers during repair.

So, SRP is a principle explaining HOW to decompose, that is, where to draw the separation line .

He says that it is necessary to decompose according to the principle of division of "responsibility", that is, according to the tasks of certain objects.

Let us return to the drinker and the pluses that a monkey man gets when decomposing:

• The code has become very clear at every level.
• The code can be written by several programmers at once (each writing a separate element)
• Automatic testing is simplified - the simpler the element, the easier it is to test it.
• Of these three operations, in the future, you will be able to fold a glutton (using only TakeBitOperation ), Alcoholic (using only DrinkUpOperation directly from the bottle) and satisfy many other business requirements.

And, of course, cons:

• We'll have to create more types.
• The drinker will drink for the first time a couple of hours later than it could

Definition 2. Uniform variability.

Let the gentlemen! The class of drinkers also fulfills a single responsibility - it drinks! And in general, the word "responsibility" is a very vague concept. Someone is responsible for the fate of mankind, and someone is responsible for raising penguins overturned at the pole.

Consider two implementations of drinking. The first, mentioned above, contains three classes - pour, drink and snack.

The second, written through the methodology "Forward and only forward" and contains all the logic in the Act method:

 //      .    lass BrutTippler { //... void Act(){ //  if(!_hand.TryDischarge(from:_bottle, to:_glass, size:_glass.Capacity)) throw new OverdrunkException(); //  if(!_hand.TryDrink(from: _glass, size: _glass.Capacity)) throw new OverdrunkException(); // for(int i = 0; i< 3; i++){ var food = _foodStore.TakeOrDefault(); if(food==null) throw new FoodIsOverException(); _hand.TryEat(food); } } } 

Both of these classes, from the point of view of an outsider, look absolutely the same and fulfill the single responsibility of “drinking”.

Embarrassment!

Then we climb into the Internet and find out another definition of SRP - the principle of uniform variability.

This definition states that " The module has one and only one reason for change ." That is, "Responsibility is a reason for change."

Now everything falls into place. Separately, you can change the procedures for pouring, drinking and snacking, and in the drinker itself we can only change the sequence and composition of operations, for example, by moving the snack before drinking or adding a toast reading.

In the "Forward and only forward" approach, all that can be changed is changed only in the Act method. This can be readable and efficient in the case where there is little logic and it rarely changes, but often it ends in terrible methods with 500 lines each, with the number of if -s greater than is required for Russia to join NATO.

Definition 3. Localization of changes.

Drinkers often do not understand why they woke up in someone else’s apartment, or where they were mobile. It's time to add detailed logging.

Let's start logging with the pouring process:

 class PourOperation: IOperation{ PourOperation(ILogger log /*....*/){/*...*/} //... void Do(){ _log.Log($"Before pour with {_hand} and {_bottle}"); //Pour business logic ... _log.Log($"After pour with {_hand} and {_bottle}"); } } 

Having encapsulated it in PourOperation , we acted wisely from the point of view of responsibility and encapsulation, but now with the principle of variability we are now confused. In addition to the operation itself, which can change, logging itself becomes changeable. It is necessary to separate and make a special logger for the pouring operation:

 interface IPourLogger{ void LogBefore(IHand, IBottle){} void LogAfter(IHand, IBottle){} void OnError(IHand, IBottle, Exception){} } class PourOperation: IOperation{ PourOperation(IPourLogger log /*....*/){/*...*/} //... void Do(){ _log.LogBefore(_hand, _bottle); try{ //... business logic _log.LogAfter(_hand, _bottle"); } catch(exception e){ _log.OnError(_hand, _bottle, e) } } } 

The meticulous reader will notice that LogAfter , LogBefore and OnError can also change separately, and by analogy with the previous actions will create three classes: PourLoggerBefore , PourLoggerAfter and PourErrorLogger .

And remembering that there are three operations for drinking, we get nine logging classes. As a result, the whole drinker consists of 14 (!!!) classes.

Hyperbola? Hardly! A monkey man with a decomposition grenade will crush the “pouring” into a decanter, a glass, pouring operators, a water supply service, a physical model of molecular collisions, and the next quarter will try to unravel dependencies without global variables. And believe me - it will not stop.

It is at this point that many come to the conclusion that the SRP are fairy tales from the pink kingdoms, and they leave the noodles ...

... without knowing about the existence of the third definition of Srp:

" Similar things for change should be kept in one place ." or “ What changes together should be kept in one place ”

That is, if we change the operation logging, then we should change it in one place.

This is a very important point - since all the SRP explanations that were above said that it was necessary to split up the types while they were split up, that is, they imposed a "top limit" on the object size, and now we are already talking about the "bottom limit" . In other words, the SRP not only requires "to break up while it is being crushed," but also not to overdo it - "not to crush the linked things . " Do not complicate unnecessarily. This is the great battle of Occam's razor with the ape-man!

Now the drinker should be easier. In addition to not splitting the IPourLogger logger into three classes, we can also combine all loggers into one type:

 class OperationLogger{ public OperationLogger(string operationName){/*..*/} public void LogBefore(object[] args){/*...*/} public void LogAfter(object[] args){/*..*/} public void LogError(object[] args, exception e){/*..*/} } 

And if we add the fourth type of operation, then logging is ready for it. And the code of the operations themselves is clean and free from infrastructural noise.

As a result, we have 5 classes for solving the problem of drinking:

• Pouring operation
• Drinking operation
• Bind operation
• Logger
• Facade drinkers

Each of them is responsible strictly for one functionality, has one reason for the change. All similar to change the rules are next.

Real life examples

 User{ String Name; Int Age; } 

 UserDeserializer{ String deserialize(User){...} } UserSerializer{ User serialize(String){...} } 

 UserSerializer{ String deserialize(User){...} User serialize(String){...} } 

 void SaveGain(Company company){ //     //   } 

 Gain CalcGain(Company company){..} void SaveGain(Gain gain){..} 

Formalism.

It's time to leave our drinker alone. Wipe your tears - we will definitely return to it somehow. And now we formalize the knowledge from this article.

Formalism 1. Definition of SRP

1. Separate the elements so that each of them is responsible for one thing.
2. Responsibility stands for "reason for change." That is, each element has only one reason to change, in terms of business logic.
3. Potential changes in business logic. must be localized. Variable items must be nearby.

Formalism 2. Necessary self-verification criteria.

I have not met sufficient criteria for the implementation of SRP. But there are necessary conditions:

1) Ask yourself the question - what does this class / method / module / service do? you must answer it with a simple definition. (thanks to Brightori )

2) Fixing some bug or adding a new feature affects the minimum number of files / classes. Ideally, one.

3) If several developers are working on different features of your project, then the probability of a merge conflict, that is, the likelihood that the same file / class will be changed by several developers at the same time is minimal.

4) For a clarifying question about business logic (from a developer or manager), you climb strictly into one class / file and receive information only from there.

5) Naming is understandable.

Formalism 3. The method of development "Occam-first."

At the beginning of the design, the monkey-man does not know and does not feel all the subtleties of the problem being solved and can give a blunder. You can be mistaken in different ways:

• Make too large objects, sticking together different responsibilities
• Pererobit, dividing the responsibility for many different types
• Invalid boundaries

It is important to remember the rule: “it’s better to err on the big side,” or “not sure - don’t split up. If, for example, your class brings together two responsibilities - then it is still understandable and can be cut into two with minimal change in client code. Collecting glass from glass fragments is usually more difficult due to the context smeared over several files and the lack of necessary dependencies in the client code.

Time to wrap up

The scope of the SRP is not limited to OOP and SOLID. It is applicable to methods, functions, classes, modules, microservices, and services. It is applicable both to figax-figax-and-in-prod, and to “rocket seins” development, making the world a little better everywhere. If you think about it, then this is almost the fundamental principle of all engineering. Mechanical engineering, control systems, and indeed all complex systems are built from components, and “incomplete crafting” deprives designers of flexibility, “fragmentation” of efficiency, and incorrect boundaries — of reason and peace of mind.

SRP is not invented by nature and is not part of exact science. He gets out of our biological and psychological limitations. This is just a way to control and develop complex systems with the help of the human-monkey's brain. He tells us how to decompose the system. The original wording required a fair amount of telepathy, but I hope this article slightly dispelled the smoke screen.