Principen om enkel ansvarighet. Inte så enkelt som det verkar

Single responsibility principle, även känt som principen för enhetligt ansvar,
den är också principen för enhetlig förändring – en ganska glidig och nervös fråga under programmerarintervjuer.

Min första seriösa bekantskap med denna princip skedde i början av första terminen, när vi, unga och gröna, blev tagna till skogen för att göra om studenterna till riktiga studenter.

I skogen delades vi upp i grupper om 8-9 personer i varje och en tävling anordnades – vilken grupp som snabbast kunde dricka en flaska vodka, med förutsättningen att den första personen i gruppen häller vodka i glaset, den andra dricker och den tredje äter något. Den som genomfört sin uppgift ställer sig sist i kön.

Situationen där kön var delbar med tre var en bra implementering av SRP.

Definition 1. Enhetligt ansvar.

Den officiella definitionen av principen för enhetligt ansvar (SRP) säger att varje objekt har ett eget ansvar och skäl att existera, och detta ansvar är endast ett.

Låt oss betrakta objektet "Tippler" (Tippler).
För att tillämpa SRP delar vi upp ansvaret på tre:

• En häller (PourOperation)
• En dricker (DrinkUpOperation)
• En äter (TakeBiteOperation)

Varje deltagare i processen ansvarar för en komponent av processen, vilket innebär att de har ett atomärt ansvar – att dricka, hälla eller äta.

Tipplern är å sin sida en fasad för dessa operationer:

class Tippler {
    //...
    void Act(){
        _pourOperation.Do() // hälla
        _drinkUpOperation.Do() // dricka
        _takeBiteOperation.Do() // äta
    }
}

Varför?

Människan-programmeraren skriver kod för människan-apan, och människan-apan är ouppmärksam, dum och rusar alltid vidare någonstans. Han kan hålla och förstå cirka 3 till 7 termer vid ett och samma tillfälle.
I fallet med Tipplern är dessa termer tre. Men om vi skriver koden som en lång text, så dyker händer, glas, slagsmål och oändliga diskussioner om politik upp. Och allt detta kommer att vara i kroppen av en metod. Jag är säker på att du har sett sådan kod i din praktik. Det är inte det mest humana provet för psyket.

Å andra sidan är människan-apa inriktad på att modellera verkliga objekt i sitt sinne. I sin fantasi kan han krocka dem, bygga nya objekt och dismantla dem på samma sätt. Tänk dig en gammal bilmodell. Du kan i fantasin öppna dörren, skruva bort dörrens klädsel och se mekanismerna för fönsterhissarna, där det finns kugghjul. Men du kan inte se alla bilens komponenter samtidigt, i en "lista". Åtminstone kan "människan-apa" inte.

Därför dekomponerar programmerande människor komplexa mekanismer i en uppsättning mindre komplexa och fungerande element. Men de kan dekomponera på olika sätt: i många gamla bilar går luftkanalen ut i dörren, medans en modern bils elektroniska lås kan misslyckas och hindra motorn från att starta, vilket kan vara frustrerande vid reparation.

Så SRP är en princip som förklarar HUR man dekomponerar, det vill säga var man ska dra linjen för uppdelning..

Det säger att man ska dekomponera utifrån principen om "ansvarsfördelning", det vill säga utifrån uppgifterna hos olika objekt.

Låt oss återvända till dryckaren och de fördelar som människan-apa får vid dekomponering:

• Koden blir mycket tydlig på varje nivå.
• Koden kan skrivas av flera programmerare samtidigt (var och en skriver ett separat element).
• Automatiserad testning underlättas — ju enklare elementet är, desto lättare är det att testa.
• Kodens komposition framträder — det går att byta ut DrinkUpOperation mot en operation där dryckaren häller ut vätska under bordet. Eller byta ut hälloperationen mot en där du blandar vin och vatten eller vodka och öl. Beroende på affärens krav kan du göra allt detta utan att röra koden för metoden. Tippler.Act.
• Utifrån dessa operationer kan du kombinera glutton (använder bara TakeBitOperation), alkoholisten (använder bara DrinkUpOperation direkt från flaskan) och uppfylla många andra affärsbehov.

(Ojdå, ser ut som detta redan är en OCP-princip, och jag har brutit mot detta inläggets ansvar.)

Och såklart, nackdelarna:

• Det kommer att krävas att skapa fler typer.
• Dryckaren kommer att dricka ett par timmar senare än han skulle kunna.

Definition 2. Enhetlig förändring.

Låt oss vara ärliga, herrar! Klassen av drinkare har också ett enda ansvar – att dricka! Och överhuvudtaget är ordet "ansvar" ett extremt diffust begrepp. Någon är ansvarig för mänsklighetens öde, medan någon annan är ansvarig för att hjälpa upp slipade pingviner på polen.

Låt oss betrakta två implementationer av drinkaren. Den första, som nämndes ovan, innehåller tre klasser – hälla, dricka och snaska.

Den andra, skriven med metodologin "Framåt och bara framåt", innehåller all logik i metoden Act:

//Не тратьте время  на изучение этого класса. Лучше съешьте печеньку
с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);
    }
   }
}

Båda dessa klasser, från en extern observatörs perspektiv, ser helt lika ut och har det enda ansvaret "att dricka".

Klausul!

Då tar vi oss en titt på internet och lär oss en annan definition av SRP – Principen om enstaka förändring (Single Changeability Principle).

SCP säger att "Modulen har en och enbart en anledning till förändring". Det vill säga "Ansvar är anledningen till förändring".

(Tydligen var killarna som kom på den ursprungliga definitionen övertygade om människans telepatiska förmågor)

Nu faller allt på plats. Separat kan vi ändra procedurerna för att hälla, dricka och snaska, och i själva drinkaren kan vi bara ändra sekvensen och sammansättningen av operationerna, till exempel genom att flytta snacket till före drickandet eller lägga till en skål.

I ansatsen "Framåt och bara framåt" kan det som går att ändra – ändras endast i metoden Act. Detta kan vara läsbart och effektivt när logiken är minimal och sällan förändras, men ofta slutar det med hemska metoder på 500 rader vardera, med fler if-satser än som krävs för att Ryssland ska gå med i NATO.

Definition 3. Lokalisering av förändringar.

Drinkare förstår ofta inte varför de vaknar i någon annans lägenhet, eller var deras mobiltelefon är. Det är dags att lägga till detaljerad loggning.

Vi börjar loggningen med hällprocessen:

class PourOperation: IOperation{
    PourOperation(ILogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.Log($"Innan hällning med {_hand} och {_bottle}");
        //Häll affärslogik ...
        _log.Log($"Efter hällning med {_hand} och {_bottle}");
    }
}

Inkaplulerar den i PourOperation, vi har agerat klokt när det gäller ansvar och inkapsling, men nu har vi en klurig situation när det gäller föränderliga principer. Utöver själva operationen, som kan förändras, blir även loggningen förändlig. Vi kommer att behöva separera och skapa en specialiserad loggare för hälloperationen:

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{
             //... affärslogik
             _log.LogAfter(_hand, _bottle);
        }
        catch(exception e){
            _log.OnError(_hand, _bottle, e);
        }
    }
}

Den noggranna läsaren kommer att märka att LogAfter, LogBefore och OnError kan också förändras separat, och i likhet med tidigare åtgärder kommer tre klasser att skapas: PourLoggerBefore, PourLoggerAfter och PourErrorLogger.

Och med tanke på att det finns tre operationer för hällandet, får vi nio loggningsklasser. Totalt består hälloperationen av 14 (!!!) klasser.

Hyperbol? Sannolikt inte! Människoskapelsen med en dekompositionsgranat kommer att krossa "hällaren" i karaff, glas, hälloperatörer, vattenleveransservice, den fysiska modellen för molekylkollisioner, och under nästa kvartal kommer den att försöka reda ut beroenden utan globala variabler. Och tro mig - den kommer inte att stanna.

Just vid detta tillfälle kommer många till slutsatsen att SRP är sagor från rosafärgade kungadömen och går iväg for att skapa illusioner...

... utan att veta om existensen av den tredje definitionen av SRP:

«Principen om enhetligt ansvar säger att liknande objekt för förändring bör förvaras på ett ställe». eller “Det som förändras tillsammans bör förvaras på ett ställe.”

Det vill säga, om vi ändrar loggningen av operationen, så måste vi göra det på ett ställe.

Detta är en mycket viktig punkt - eftersom alla tidigare förklaringar av SRP handlade om att man ska dela typer, så länge de kan delas, därmed lade det "övre begränsningar" på objektets storlek, och nu talar vi även om "nedre begränsningar". Med andra ord, SRP kräver inte bara att man "delar så länge det går", utan också att man inte överdriver - "inte dela sammanbundna saker".. Detta är det stora slaget mellan Ockhams rakkniv och människoskapelsen!

Nu bör det bli lättare för hällaren. Förutom att vi inte behöver dela loggaren IPourLogger i tre klasser, kan vi också samla alla loggare i en typ:

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

Och om vi lägger till en fjärde typ av operation, så är loggningen redan klar för den. Och koden för själva operationerna är ren och fri från infrastruktursbrus.

Resultatet är att vi har 5 klasser för att lösa problemet med drickande:

• Hägningsoperation
• Uppdragsutförande
• Ätandeoperation
• Loggskribent
• Bara för drickande

Varje klass ansvarar strikt för en funktionalitet och har ett enda skäl för förändring. Alla liknande regler för förändring ligger nära varandra.

Exempel från verkliga livet

En gång skrev vi en tjänst för automatisk registrering av b2b-kunder. Och en GOD-metod på 200 rader liknande innehåll dök upp:

• Gå till 1C och registrera ett konto
• Med det kontot, gå till betalningsmodulen och registrera det där
• Kontrollera att ett konto med det kontot inte redan finns i huvudsystemet servern
• Skapa ett nytt konto
• Registreringsresultatet i betalningsmodulen och numret 1C läggs till i registreringstjänsten
• Lägg till information om kontot i den här tabellen
• Skapa en punktnummer för den här kunden i punkttjänsten. Skicka punktnumret 1C till den tjänsten.

Och det fanns omkring 10 andra affärsoperationer i den här listan med fruktansvärd koppling. Kontoobjektet behövdes av nästan alla. Punktidentifierare och kundnamn behövdes i hälften av anropen.

Efter en timmes refaktorering kunde vi separera infrastrukturskoden och vissa nyanser av arbete med kontot i separata metoder/klasser. Godmetoden blev lättare, men fortfarande fanns det 100 rader kod som inte ville lösa sig.

Först efter några dagar kom förståelsen att kärnan i denna "lättare" metod är själva affärsalgoritmen. Och att den ursprungliga specifikationen av krav var ganska komplex. Och just försöket att dela upp denna metod skulle vara ett brott mot SRP, snarare än tvärtom.

Formalism.

Det är dags att lämna vår drickare i fred. Torka tårarna - vi kommer definitivt att återkomma till honom någon gång. Men nu formaliserar vi kunskaperna från denna artikel.

Formalism 1. Definition av SRP

1. Separera element så att var och en av dem ansvarar för något enskilt.
2. Ansvar översätts som "skäl för förändring". Det vill säga varje element har bara ett skäl för förändring, i termer av affärslogik.
3. Potentiella förändringar av affärslogik måste lokaliseras. Ändringsbara synkrona element bör placeras nära varandra.

Formalism 2. Nödvändiga självgenererade kriterier.

Jag har inte stött på tillräckliga kriterier för att uppfylla SRP. Men det finns nödvändiga villkor:

1) Ställ dig själv frågan - vad gör denna klass/metod/modul/tjänst. Du bör kunna svara på den med en enkel definition. (Tack) Brightori )

förklaringar

Det är dock ibland mycket svårt att hitta en enkel definition

2) Fixandet av ett visst fel eller tillägg av en ny funktion påverkar ett minimalt antal filer/klasser. Idealiskt - en.

förklaringar

Eftersom ansvaret (för funktionen eller felet) är inkapslat i en fil/klass, vet du exakt var du ska leta och vad du ska ändra. Till exempel: funktionen för att ändra loggningen av operationer kräver endast att loggaren ändras. Det behövs inte att jaga runt i resten av koden.

Ett annat exempel - tillägget av en ny UI-kontroll, liknande tidigare. Om detta får dig att behöva lägga till 10 olika enheter och 15 olika konverterare - tycks det som om du har "överarbetat".

3) Om flera utvecklare arbetar med olika funktioner i ditt projekt, så är risken för merge-konflikt, det vill säga risken för att samma fil/klass ändras av flera utvecklare samtidigt - minimal.

förklaringar

Om tillägget av en ny operation "Hälla vodka under bordet" kräver att du berör loggaren, operationshällning och -drickande - tyder det på att ansvarigheten har delats upp dåligt. Självklart är detta inte alltid möjligt, men det är viktigt att försöka minska detta mått.

4) Vid klargörande frågor om affärslogik (från utvecklaren eller managern) gräver du strikt i en enda klass/fil och får informationen endast därifrån.

förklaringar

Funktioner, regler eller algoritmer skrivs kompakt, var och en på en plats, och inte spridda som flaggor över hela kodutrymmet.

5) Namngivningen är tydlig.

förklaringar

Vår klass eller metod är ansvarig för något enda, och ansvaret återspeglas i dess namn

AllManagersManagerService - är förmodligen en Gud-klass
LocalPayment - sannolikt inte

Formalism 3. Utvecklingsmetodik "Ockham-first".

I början av designen vet inte apmannen alla nyanser av det problem som ska lösas och kan göra misstag. Man kan fela på olika sätt:

• Att göra för stora objekt genom att klistra samman olika ansvar
• Att dela upp ett enhetligt ansvar i många olika typer
• Felaktigt definiera gränser för ansvar

Det är viktigt att komma ihåg regeln: "bättre att göra misstag åt det stora hållet", eller "om du är osäker - dela inte upp". Om till exempel din klass har två ansvar - så är den fortfarande förståelig och kan delas upp i två med minimal förändring av kundkoden. Att samla ett glas av krossat glas är i regel svårare på grund av det spridda sammanhanget över flera filer och bristen på nödvändiga beroenden i kundkoden.

Det är dags att avrunda

Tillämpningsområdet för SRP är inte begränsat till OOP och SOLID. Det är tillämpligt på metoder, funktioner, klasser, moduler, mikrotjänster och tjänster. Det är tillämpligt både på "fixa-fixa-och-i-produktion" och "raketvetenskap" utveckling, och gör världen lite bättre överallt. Om man tänker efter är det knappt inte en grundläggande princip för all ingenjörskonst. Maskinteknik, styrsystem och faktiskt alla komplexa system byggs av komponenter, och "underuppdelning" tar bort konstruktörernas flexibilitet, "överuppdelning" tar bort effektiviteten, och felaktiga gränser tar bort förnuft och själslig ro.

SRP är inte upptäckt av naturen och är inte en del av en exakt vetenskap. Det kommer från våra biologiska och psykologiska begränsningar. Det är helt enkelt ett sätt att kontrollera och utveckla komplexa system med hjälp av den mänskliga apan. Det lär oss hur man dekomponerar ett system. Den ursprungliga formuleringen krävde en hel del telepatiska färdigheter, men jag hoppas att denna artikel har lyft lite av dimman.

Källa: habr.com