Single Responsibility Principle. Не е толкова прост, колкото изглежда

Принцип на единствената отговорност,
което също е принцип на единната изменчивост — изключително неясен за разбиране въпрос и изключително нервен в контекста на интервю за работа за програмист.

Първото сериозно запознанство с този принцип беше в началото на първата година, когато ни заведе в гората, за да направи от личинките студенти — истински студенти.

В гората ни разделиха на групи по 8-9 човека и организираха състезание — коя група по-бързо ще изпие бутилка водка, при условие, че първият човек от групата налива водка в чашата, вторият я изпива, а третият закусва. Извършил операцията участник застава в края на опашката на групата.

Случай, когато размерът на опашката беше кратен на три, и беше добра реализация на SRP.

Определение 1. Единна отговорност.

Официалното определение на принципа на единната отговорност (SRP) казва, че всеки обект има своя собствена отговорност и причина за съществуване и тази отговорност е само една.

Нека разгледаме обект «Направляващ» (Tippler).
За да изпълним принципа SRP, разпределяме задълженията на трима:

• Един налива (PourOperation)
• Един изпива (DrinkUpOperation)
• Един закусва (TakeBiteOperation)

Всеки от участниците в процеса е отговорен за една компонента на процеса, тоест има една атомарна отговорност — да изпие, да налее или да закусва.

Направляващият, от своя страна, е фасада за данните операции:

сlass Tippler {
    //...
    void Act(){
        _pourOperation.Do() // налей
        _drinkUpOperation.Do() // изпий
        _takeBiteOperation.Do() // закуска
    }
}

ЗАЩО?

Човек-програмист пише код за човек-маймуна, а човек-маймуна е небрежен, глупав и постоянно бърза за някъде. Той може да запомни и разбере около 3—7 термина в един момент на време.
В случая на направляващия, тези термини са три. Въпреки това, ако напишем кода в една дълга поредица, в него ще се появят ръце, чаши, бой и безкрайни спорове за политика. И всичко това ще бъде в тялото на един метод. Сигурен съм, че сте виждали такъв код в практиката си. Не е най-хуманното изпитание за психиката.

От една страна, човекът-обезяна е затворен в моделирането на обекти от реалния свят в съзнанието си. В своето въображение той може да ги сблъсква, да събира нови обекти от тях и да ги разглобява по същия начин. Представете си стара модел на кола. Можете да си представите как отваряте вратата, развивате обшивката на вратата и виждате механизмите на стъклодърпачките, в които ще има зъбчати колела. Но не можете да видите всички компоненти на колата едновременно, в един "листван" формат. Най-малкото "човекът-обезяна" не може.

Затова програмистите често декомпозира сложни механизми на набор от по-малко сложни и работещи елементи. Въпреки това, декомпозицията може да се извърши по различни начини: в много стари коли — въздуховодът излиза вратата, а в съвременните — повреда в електрониката на ключалката не позволява да стартира двигателя, което затруднява ремонта.

Така че, SRP — това е принцип, който обяснява КАК да се декомпозира, т.е. къде да се начертае линия на разделение.

Той казва, че декомпозицията трябва да се извършва въз основа на принципа на "разделение на отговорностите", т.е. според задачите на различни обекти.

Нека се върнем към пияницата и плюсовете, които получава човекът-обезяна при декомпозиране:

• Кодът стана изключително ясни на всяко ниво
• Кодът може да бъде написан от няколко програмисти едновременно (всеки пише отделен елемент)
• Автоматичното тестване се опростява — колкото по-опростен е елементът, толкова по-лесно е да го тествате
• Появява се композиционност на кода — можете да заменяте DrinkUpOperation действие, в което пияницата излива течност под масата. Или да замените операцията на наливане с операция, в която смесвате вино и вода или водка и бира. В зависимост от бизнес изискванията, можете да правите всичко това, без да докосвате кода на метода Tippler.Act.
• От тези операции можете да сглобите ядрената (използвайки само TakeBitOperation), Алкохолика (използвайки само DrinkUpOperation напряко от бутилката) и да задоволите много други бизнес изисквания.

(Ой, изглежда, че това вече е принципът OCP и наруших отговорността на този пост)

И, разбира се, минусите:

• Ще трябва да създадете повече типове.
• Пияницата за първи път ще пие с няколко часа по-късно, отколкото би могъл

Определение 2. Еднаква променливост.

Позволете, господа! Класът на пияниците също така изпълнява единствената отговорност — той пие! И изобщо, понятието "отговорност" е крайно разметено. Някой е отговорен за съдбата на човечеството, а някой е отговорен за вдигането на обърнати на полюса пингвини.

Нека разгледаме две реализации на пияницата. Първата, посочена по-горе, съдържа три класа — наливам, пия и хапвам.

Втората е написана по методологията "Напред и само напред" и съдържа цялата логика в метода 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);
    }
   }
}

И двата тези класа, от гледна точка на външен наблюдател, изглеждат абсолютно идентично и изпълняват единствената отговорност "да пият".

Конфуз!

Тогава влизаме в интернет и научаваме друго определение на SRP — Принцип на единствената изменчивост (Single Changeability Principle).

SCP гласи, че "Модулът има само една причина за изменение". Тоест "Отговорността е причината за изменение".

(Изглежда, че хората, които са измислили първоначалното определение, са били уверени в телепатичните способности на човека-обезяна)

Сега всичко си идва на мястото. Отделно можем да променяме процедурите за наливане, пиене и хапване, а в самата пияница можем да променим само последователността и състава на операциите, например, да преместим хапването преди пиенето или да добавим четене на тост.

В подхода "Напред и само напред", всичко, което може да се промени — се променя само в метода Act. Това може да бъде четивно и ефективно в случай, че логиката е малко и рядко се променя, но често завършва с ужасни методи по 500 реда в всеки, със значително количество if-ове, повече от необходимото за влизането на Русия в НАТО.

Определение 3. Локализация на изменения.

Пияниците често не разбират защо са се събудили в чужда квартира или къде е мобилният им телефон. Време е да добавим подробна логировка.

Нека започнем логировката с процеса на наливане:

class PourOperation: IOperation{
    PourOperation(ILogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.Log($"Преди наливане с {_hand} и {_bottle}");
        //Логика на наливането...
        _log.Log($"След наливане с {_hand} и {_bottle}");
    }
}

Инкапсулирайте я в PourOperation, ние постъпихме мъдро от гледна точка на отговорността и инкапсулацията, но сега имаме затруднение с принципа на изменчивост. Освен самата операция, която може да се променя, променлива става и самото логиране. Ще трябва да разделим и да направим специален логер за операцията наливане:

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{
             //... бизнес логика
             _log.LogAfter(_hand, _bottle);
        }
        catch(exception e){
            _log.OnError(_hand, _bottle, e)
        }
    }
}

Внимателният читател ще забележи, че LogAfter, LogBefore и OnError също могат да се променят поотделно и по аналогия с предходните действия ще създаде три класа: PourLoggerBefore, PourLoggerAfter и PourErrorLogger.

А като си спомним, че операциите за пияницата са три — получаваме девет класа за логиране. В крайна сметка целият пияница се състои от 14 (!!!) класа.

Хипербола? Малко вероятно! Човек-маймуна с декомпозиционна граната ще раздроби “наливателя” на графин, чаша, оператори на наливане, услуга за подаване на вода, физически модел на сблъсък на молекули и следващия квартал ще се опитва да разплете зависимостите без глобални променливи. И повярвайте — той няма да спре.

Точно в този момент много хора стигат до заключението, че SRP — това са приказки от розовите кралства и отиват да тъкат спагети...

… така и не разбрали за съществуването на третото определение на SRP:

«Принципът на единната отговорност гласи, че подобни за промяна неща трябва да се съхраняват на едно място«. или “Това, което се променя заедно, трябва да се съхранява на едно място.”

Иначе казано, ако променяме логиране на операцията, то трябва да променяме това на едно място.

Това е много важен момент — тъй като всички обяснения по SRP, които бяха по-горе, говореха за това, че трябва да разчупваме типовете, докато те се разчупват, тоест налагаше «ограничение отгоре» на размер на обекта, а сега говорим вече и за «ограничение отдолу». С други думи, SRP не само изисква «да се дроби, докато се дроби», но и да не се прекаляваме — «да не раздробим свързани неща». Това е великата битка на бръснача на Оккам с човека-маймуна!

Сега на пияницата би трябвало да стане по-лесно. Освен че не е нужно да се раздробява логера IPourLogger на три класа, можем също да обединим всички логери в един тип:

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

А ако добавим четвърти тип операция, вече имаме логиране за него. А кодът на самите операции е чист и освободен от инфраструктурен шум.

В резултат на това имаме 5 класа, които решават задачата по изпиване:

• Операция наливане
• Операция изпиване
• Операция заяждане
• Логиращ модул
• Фасад на пияндето

Всеки от тях е отговорен строго за една функционалност и има една причина за промяна. Всички подобни правила за промяна са в близост.

Пример от реалния живот

Един ден пишехме услуга за автоматична регистрация на B2B клиенти. И се появи методът GOD с 200 реда подобно съдържание:

• Отиди в 1С и създай акаунт
• С този акаунт отиди в модула за плащания и го създай там
• Провери и се увери, че акаунт с този акаунт не е съществувал на главния сървър
• Създай нов акаунт
• Добави резултата от регистрацията в модула за плащания и номер 1С в услугата за резултати от регистрацията
• Добави в тази таблица информация за акаунта
• Създай номер на точка за този клиент в услугата за точки. Предай на тази услуга номер на акаунт 1С.

И в този списък имаше още около 10 бизнес операции с ужасна взаимна свързаност. Обектът акаунт беше нужден почти от всички. Идентификаторът на точката и името на клиента бяха необходими в половината от повикванията.

След час рефакторинг успяхме да отделим инфраструктурния код и някои нюанси на работа с акаунта в отделни методи/класове. Методът God стана по-лек, но останаха 100 реда код, които не искаха да се разплитат.

Само след няколко дни осъзнахме, че същността на този "облекчения" метод — и е бизнес алгоритъм. И че първоначалното описание на спецификациите беше доста сложно. И именно опитът да разделим този метод на парчета ще наруши SRP, а не обратно.

Формализъм.

Дойде време да оставим нашето пиянче настрана. Изтривай сълзите — определено ще се върнем при него някой ден. А сега формализираме знанията от тази статия.

Формализъм 1. Определение на SRP

1. Разделяйте елементите така, че всеки от тях да е отговорен за нещо едно.
2. Отговорността се разшифрова като „причина за промяна“. Тоест, всеки елемент има само една причина за промяна, в термини на бизнес логиката.
3. Потенциални промени в бизнес логиката трябва да бъдат локализирани. Променяемите синхронни елементи трябва да бъдат близо до вас.

Формализъм 2. Необходими критерии за самооценка.

Не съм срещал достатъчни критерии за изпълнение на SRP. Но има необходимите условия:

1) Задайте си въпрос — какво прави този клас/метод/модул/услуга. Трябва да отговорите на него с просто определение. (благодаря Brightori )

обяснения

Все пак понякога е много трудно да се намери просто определение

2) Коригирането на даден бъг или добавянето на нова функция засяга минимален брой файлове/класове. В идеалния случай — един.

обяснения

Тъй като отговорността (за функцията или бъга) е капсулирана в един файл/клас, вие точно знаете къде да търсите и какво да поправяте. Например: функция за изменение на изхода на логовете на операциите ще изисква промяна единствено в логера. Не е необходимо да обикаляте целия останал код.

Друг пример — добавяне на нов UI контрол, подобен на предишните. Ако това ви принуждава да добавяте 10 различни единици и 15 различни конвертора — изглежда, че сте „предробили”.

3) Ако няколко разработчици работят по различни функции на вашия проект, вероятността за конфликт при сливане — тоест вероятността един и същи файл/клас да бъде променен от няколко разработчици едновременно — е минимална.

обяснения

Ако при добавянето на нова операция „Излейте водката под масата” трябва да се докоснете до логера, операцията за пиене и изливане — тогава изглежда, че отговорностите са разделени криво. Разбира се, това не винаги е възможно, но е необходимо да се стараем да намалим този показател.

4) При уточняващ въпрос за бизнес логиката (от разработчик или мениджър) вие излизате строго в един клас/файл и получавате информация само от там.

обяснения

Функциите, правилата или алгоритмите са компактно написани, всеки в едно място, а не разпръснати с флагове из цялото пространство на кода.

5) Именуването е ясно.

обяснения

Нашият клас или метод е отговорен за нещо едно, и отговорността е отразена в името му.

AllManagersManagerService — вероятно е God-клас.
LocalPayment — вероятно, не.

Формализъм 3. Методология на разработката „Оккам-първо”.

В началото на проектирането, човек-обезяна не знае и не чувства всички нюанси на решаваната задача и може да направи грешка. Грешките могат да бъдат различни:

• Да се създават прекалено големи обекти, комбинирайки различни отговорности
• Да се разчупи, разделяйки единството на отговорността на много различни типове
• Неправилно определяне на границите на отговорността

Важно е да запомните правилото: "по-добре да грешите в голямото", или "не сте сигурни - не разчупвайте". Например, ако вашият клас съдържа две отговорности - той все още е разбираем и може да бъде разделен на две с минимални изменения в клиентския код. Събирането на стъклени фрагменти в чаша, за обикновено, е по-сложно поради размазан контекст в няколко файла и липсата на необходимите зависимости в клиентския код.

Време е да приключим

Обхватът на прилагане на SRP не се ограничава до ООП и SOLID. Той е приложим за методи, функции, класове, модули, микросервизи и услуги. Той е приложим както за "figax-figax-и-в-прод", така и за "рокет-сайнс" разработка, правейки света малко по-добър навсякъде. Ако помислите, това е едва ли не основен принцип на цялата инженерия. Машиностроенето, управленските системи и изобщо всички сложни системи - се изграждат от компоненти, а "недостатъчното разделяне" лишава конструктора от гъвкавост, "прекаляването с разделянето" - от ефективност, а неправилните граници - от разум и душевно спокойствие.

SRP не е създаден от природата и не е част от точните науки. Той произтича от нашите биологични и психологически ограничения. Това е просто начин за контрол и развитие на сложни системи с помощта на човешкия мозък. Той ни показва как да декомпозируем системата. Първоначалната формулировка изискваше значителни умения за телепатия, но се надявам, че тази статия малко разсейва дима.

Източник: habr.com