Принцип на единната отговорност. Не е толкова просто, колкото изглежда

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

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

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

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

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

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

Помислете за обекта „Пияч“ (Самосвал).
За да приложим принципа на SRP, ще разделим отговорностите на три:

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

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

От своя страна дупката за пиене е фасада за тези операции:

сlass Tippler {
    //...
    void Act(){
        _pourOperation.Do() // налить
        _drinkUpOperation.Do() // выпить
        _takeBiteOperation.Do() // закусить
    }
}

Защо?

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

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

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

Сега, SRP е принцип, който обяснява КАК да се разложи, тоест къде да се направи разделителната линия.

Той казва, че е необходимо да се разложи според принципа на разделяне на „отговорността“, тоест според задачите на определени обекти.

Да се ​​върнем към пиенето и предимствата, които човекът-маймуна получава по време на разлагането:

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

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

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

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

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

Позволете, господа! Класът по пиене също носи една единствена отговорност - той пие! И като цяло думата „отговорност“ е изключително неясно понятие. Някой е отговорен за съдбата на човечеството и някой е отговорен за отглеждането на пингвините, които бяха преобърнати на полюса.

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

Вторият е написан чрез методологията „Напред и само напред“ и съдържа цялата логика в метода акт:

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

SCP заявява, че "Един модул има една и само една причина да се промени". Тоест, „Отговорността е причина за промяна“.

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

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

При подхода „Напред и само напред“ всичко, което може да се промени, се променя само в метода акт. Това може да бъде разбираемо и ефективно, когато има малко логика и рядко се променя, но често завършва с ужасни методи от 500 реда всеки, с повече изрази ако, отколкото е необходимо, за да може Русия да се присъедини към НАТО.

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

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

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

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}");
    }
}

Като го капсулирате в 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{
             //... business logic
             _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 реда с подобно съдържание:

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

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

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

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

Формализъм.

Време е да оставим нашия пияница на мира. Изтрий сълзите си - със сигурност ще се върнем към него някой ден. Сега нека формализираме знанията от тази статия.

Формализъм 1. Дефиниция на SRP

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

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

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

1) Запитайте се какво прави този клас/метод/модул/услуга. трябва да му отговорите с проста дефиниция. ( Благодаря ти Брайтори )

обяснения

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

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

обяснения

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

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

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

обяснения

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

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

обяснения

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

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

обяснения

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

AllManagersManagerService - най-вероятно клас Бог
LocalPayment - вероятно не

Формализъм 3. Методология за разработка на Occam-first.

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

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

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

Време е да го наречем ден

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

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

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