ერთიანი პასუხისმგებლობის პრინციპი. არც ისე მარტივი, როგორც ჩანს

ერთიანი პასუხისმგებლობის პრინციპი, რომელიც ასევე ცნობილია როგორც ერთიანი პასუხისმგებლობის პრინციპი,
აკა ერთიანი ცვალებადობის პრინციპი - უკიდურესად მოლიპულ ბიჭს გასაგებად და ასეთი ნერვიული კითხვა პროგრამისტის ინტერვიუზე.

ჩემი პირველი სერიოზული გაცნობა ამ პრინციპთან მოხდა პირველი კურსის დასაწყისში, როცა ახალგაზრდები და მწვანეები ტყეში წაიყვანეს, რათა ლარვებისგან სტუდენტები - ნამდვილი სტუდენტები გაეკეთებინათ.

ტყეში დავყავით 8-9 კაციან ჯგუფებად და ჩავატარეთ შეჯიბრი - რომელი ჯგუფი დალევდა ერთ ბოთლ არაყს ყველაზე სწრაფად, იმ პირობით, რომ ჯგუფიდან პირველმა არაყი ჩაასხა ჭიქაში, მეორემ დალიოს. ხოლო მესამეს აქვს საჭმელი. განყოფილება, რომელმაც დაასრულა მუშაობა, გადადის ჯგუფის რიგის ბოლოს.

შემთხვევა, როდესაც რიგის ზომა იყო სამის ჯერადი, იყო SRP-ის კარგი განხორციელება.

განმარტება 1. ერთიანი პასუხისმგებლობა.

ერთიანი პასუხისმგებლობის პრინციპის (SRP) ოფიციალურ განმარტებაში ნათქვამია, რომ თითოეულ სუბიექტს აქვს საკუთარი პასუხისმგებლობა და არსებობის მიზეზი და მას აქვს მხოლოდ ერთი პასუხისმგებლობა.

განვიხილოთ ობიექტი "სასმელი" (ტიპლერი).
SRP პრინციპის განსახორციელებლად, ჩვენ დავყოფთ პასუხისმგებლობებს სამად:

• ერთი ასხამს (PourOperation)
• ერთი სვამს (DrinkUpOperation)
• ერთს აქვს საჭმელი (TakeBiteOperation)

პროცესის თითოეული მონაწილე პასუხისმგებელია პროცესის ერთ კომპონენტზე, ანუ აქვს ერთი ატომური პასუხისმგებლობა - დალევა, დაასხით ან წასახემსებლად.

სასმელი ხვრელი, თავის მხრივ, არის ფასადი ამ ოპერაციებისთვის:

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

რატომ?

ადამიანი პროგრამისტი მაიმუნისთვის კოდს წერს, მაიმუნი კი უყურადღებო, სულელი და ყოველთვის ჩქარობს. მას შეუძლია ერთდროულად დაიჭიროს და გაიგოს დაახლოებით 3-7 ტერმინი.
მთვრალის შემთხვევაში ეს სამი ტერმინია. თუმცა, თუ კოდს ერთი ფურცლით დავწერთ, მაშინ მასში იქნება ხელები, სათვალეები, ჩხუბი და გაუთავებელი კამათი პოლიტიკაზე. და ეს ყველაფერი იქნება ერთი მეთოდის სხეულში. დარწმუნებული ვარ, თქვენ გინახავთ ასეთი კოდი თქვენს პრაქტიკაში. არ არის ყველაზე ჰუმანური ტესტი ფსიქიკისთვის.

მეორეს მხრივ, მაიმუნი ადამიანი შექმნილია იმისთვის, რომ მოახდინოს თავის თავში რეალური სამყაროს ობიექტების სიმულაცია. მის წარმოსახვაში მას შეუძლია შეაერთოს ისინი, მოაწყოს მათგან ახალი საგნები და დაშალოს ისინი იმავე გზით. წარმოიდგინეთ ძველი მოდელის მანქანა. თქვენს წარმოსახვაში შეგიძლიათ გააღოთ კარი, გააღოთ კარის მორთვა და იქ ნახოთ ფანჯრის ამწე მექანიზმები, რომელთა შიგნით იქნება გადაცემათა კოლოფი. მაგრამ თქვენ ვერ ხედავთ აპარატის ყველა კომპონენტს ერთდროულად, ერთ „ჩამონათვალში“. მაინც "მაიმუნ კაცს" არ შეუძლია.

მაშასადამე, ადამიანები პროგრამისტები ანაწილებენ რთულ მექანიზმებს ნაკლებად რთულ და სამუშაო ელემენტებად. თუმცა, მისი დაშლა შესაძლებელია სხვადასხვა გზით: ბევრ ძველ მანქანაში ჰაერის სადინარი კარებში მიდის, ხოლო თანამედროვე მანქანებში საკეტის ელექტრონიკის გაუმართაობა ხელს უშლის ძრავის ჩართვას, რაც შეიძლება პრობლემა იყოს რემონტის დროს.

ახლა, SRP არის პრინციპი, რომელიც განმარტავს, თუ როგორ უნდა დაიშალა, ანუ სად უნდა დავხატოთ გამყოფი ხაზი.

ის ამბობს, რომ აუცილებელია დაშლა „პასუხისმგებლობის“ დაყოფის პრინციპის მიხედვით, ანუ გარკვეული ობიექტების ამოცანების მიხედვით.

დავუბრუნდეთ სასმელს და იმ უპირატესობებს, რომლებსაც მაიმუნი კაცი იღებს დაშლის დროს:

• კოდი ძალიან ნათელი გახდა ყველა დონეზე
• კოდი შეიძლება დაწეროს რამდენიმე პროგრამისტმა ერთდროულად (თითოეული წერს ცალკეულ ელემენტს)
• ავტომატური ტესტირება გამარტივებულია - რაც უფრო მარტივია ელემენტი, მით უფრო ადვილია მისი ტესტირება
• ჩნდება კოდის შემადგენლობა - შეგიძლიათ შეცვალოთ DrinkUpOperation ოპერაციას, რომლის დროსაც მთვრალი ასხამს სითხეს მაგიდის ქვეშ. ან შეცვალეთ ჩამოსხმის ოპერაცია ოპერაციით, რომელშიც შეურიეთ ღვინო და წყალი ან არაყი და ლუდი. ბიზნესის მოთხოვნებიდან გამომდინარე, შეგიძლიათ გააკეთოთ ყველაფერი მეთოდის კოდის შეხების გარეშე Tippler.იმოქმედე.
• ამ ოპერაციებიდან შეგიძლიათ დაკეცოთ წებოვანა (მხოლოდ გამოყენებით 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, შესვლა ადრე и ერთი შეცდომა ასევე შეიძლება შეიცვალოს ინდივიდუალურად და, წინა ნაბიჯების ანალოგიით, შეიქმნება სამი კლასი: PourLogger ადრე, PourLoggerAfter и PourErrorLogger.

და გავიხსენოთ, რომ სასმელისთვის სამი ოპერაციაა, ჩვენ ვიღებთ ხე-ტყის ცხრა კლასს. შედეგად, მთელი სასმელი წრე შედგება 14 (!!!) კლასისგან.

ჰიპერბოლა? ძლივს! მაიმუნი კაცი დაშლის ხელყუმბარით დაყოფს „ჩამსხმელს“ დეკანტერში, ჭიქაში, ჩასხმის ოპერატორებად, წყალმომარაგების სერვისად, მოლეკულების შეჯახების ფიზიკურ მოდელად და მომდევნო კვარტალში ის შეეცდება გაერკვია დამოკიდებულებები. გლობალური ცვლადები. და მერწმუნეთ, ის არ გაჩერდება.

ამ დროს ბევრი მიდის იმ დასკვნამდე, რომ SRP არის ზღაპრები ვარდისფერი სამეფოებიდან და მიდიან ლაფსის სათამაშოდ...

... Srp-ის მესამე დეფინიციის არსებობის შესახებ ოდესმე შესწავლის გარეშე:

„ერთიანი პასუხისმგებლობის პრინციპი ამბობს, რომ ცვლილებების მსგავსი ნივთები უნდა ინახებოდეს ერთ ადგილას". ან "რა ცვლილებები ერთად უნდა ინახებოდეს ერთ ადგილას"

ანუ, თუ ჩვენ შევცვლით ოპერაციის ლოგინგს, მაშინ ის უნდა შევცვალოთ ერთ ადგილას.

ეს ძალიან მნიშვნელოვანი პუნქტია - რადგან SRP-ის ყველა ახსნა-განმარტება, რომელიც ზემოთ იყო ნათქვამი, რომ საჭირო იყო ტიპების დამსხვრევა მათი დამსხვრევისას, ანუ მათ დააწესეს „ზემოდან შეზღუდვა“ ობიექტის ზომაზე და ახლა ჩვენ ვსაუბრობთ „ქვემოდან შეზღუდვაზე“. Სხვა სიტყვებით, SRP არა მხოლოდ მოითხოვს „დამსხვრევას დაქუცმაცებისას“, არამედ არ გადააჭარბოს მას - „ნუ დაამტვრევთ ურთიერთდაკავშირებულ ნივთებს“. ეს არის დიდი ბრძოლა ოკამის საპარსსა და მაიმუნის კაცს შორის!

ახლა მსმელმა თავი უკეთ უნდა იგრძნოს. გარდა იმისა, რომ არ არის საჭირო IPourLogger logger-ის სამ კლასად დაყოფა, ჩვენ ასევე შეგვიძლია გავაერთიანოთ ყველა ლოგერი ერთ ტიპად:

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 კლიენტის ავტომატურად რეგისტრაციისთვის. და ღმერთის მეთოდი გამოჩნდა მსგავსი შინაარსის 200 სტრიქონისთვის:

• გადადით 1C-ზე და შექმენით ანგარიში
• ამ ანგარიშით გადადით გადახდის მოდულზე და შექმენით იგი იქ
• შეამოწმეთ, რომ ასეთი ანგარიშის ანგარიში არ არის შექმნილი მთავარ სერვერზე
• Ახალი ანგარიშის გახსნა
• დაამატეთ რეგისტრაციის შედეგები გადახდის მოდულში და 1c ნომერი რეგისტრაციის შედეგების სერვისს
• დაამატეთ ანგარიშის ინფორმაცია ამ ცხრილში
• შექმენით პუნქტის ნომერი ამ კლიენტისთვის პუნქტის სერვისში. გადაეცით თქვენი 1c ანგარიშის ნომერი ამ სერვისს.

და იყო კიდევ 10 ბიზნეს ოპერაცია ამ სიაში საშინელი კავშირით. თითქმის ყველას სჭირდებოდა ანგარიშის ობიექტი. ზარების ნახევარში საჭირო იყო წერტილის ID და კლიენტის სახელი.

ერთსაათიანი რეფაქტორირების შემდეგ ჩვენ შევძელით ინფრასტრუქტურის კოდის და ანგარიშთან მუშაობის ზოგიერთი ნიუანსის ცალკე მეთოდებად/კლასებად გამოყოფა. ღმერთის მეთოდმა გააადვილა, მაგრამ დარჩა კოდის 100 სტრიქონი, რომელთა ამოხსნა უბრალოდ არ სურდა.

მხოლოდ რამდენიმე დღის შემდეგ გაირკვა, რომ ამ "მსუბუქი" მეთოდის არსი არის ბიზნეს ალგორითმი. და რომ ტექნიკური მახასიათებლების ორიგინალური აღწერა საკმაოდ რთული იყო. და ეს არის ამ მეთოდის ნაწილებად დაშლის მცდელობა, რომელიც დაარღვევს SRP-ს და არა პირიქით.

ფორმალიზმი.

დროა მარტო დავტოვოთ ჩვენი მთვრალი. გაიმშრალე ცრემლები - ჩვენ აუცილებლად დავუბრუნდებით მას ოდესმე. ახლა მოდით გავაფორმოთ ცოდნა ამ სტატიიდან.

ფორმალიზმი 1. SRP-ის განმარტება

1. გამოყავით ელემენტები ისე, რომ თითოეული მათგანი პასუხისმგებელია ერთ რამეზე.
2. პასუხისმგებლობა ნიშნავს „შეცვლის მიზეზს“. ანუ, თითოეულ ელემენტს აქვს ცვლილების მხოლოდ ერთი მიზეზი, ბიზნეს ლოგიკის თვალსაზრისით.
3. პოტენციური ცვლილებები ბიზნეს ლოგიკაში. ლოკალიზებული უნდა იყოს. ელემენტები, რომლებიც სინქრონულად იცვლება, ახლოს უნდა იყოს.

ფორმალიზმი 2. აუცილებელი თვითშემოწმების კრიტერიუმები.

მე ვერ ვნახე საკმარისი კრიტერიუმები SRP-ის შესასრულებლად. მაგრამ არის აუცილებელი პირობები:

1) ჰკითხეთ საკუთარ თავს, რას აკეთებს ეს კლასი/მეთოდი/მოდული/მომსახურება. თქვენ უნდა უპასუხოთ მას მარტივი განმარტებით. ( Გმადლობთ ბრაიტორი )

განმარტებები

თუმცა, ზოგჯერ ძალიან რთულია მარტივი განმარტების პოვნა

2) შეცდომის გამოსწორება ან ახალი ფუნქციის დამატება გავლენას ახდენს ფაილების/კლასების მინიმალურ რაოდენობაზე. იდეალურ შემთხვევაში - ერთი.

განმარტებები

ვინაიდან პასუხისმგებლობა (მახასიათებლებზე ან შეცდომებზე) არის ჩასმული ერთ ფაილში/კლასში, თქვენ ზუსტად იცით სად უნდა ნახოთ და რა უნდა შეცვალოთ. მაგალითად: ჩაწერის ოპერაციების გამომუშავების შეცვლის ფუნქცია მოითხოვს მხოლოდ ლოგერის შეცვლას. არ არის საჭირო დანარჩენი კოდის გაშვება.

კიდევ ერთი მაგალითია ახალი UI კონტროლის დამატება, წინა მსგავსი. თუ ეს გაიძულებთ დაამატოთ 10 სხვადასხვა ერთეული და 15 განსხვავებული გადამყვანი, როგორც ჩანს, გადაჭარბებული ხართ.

3) თუ რამდენიმე დეველოპერი მუშაობს თქვენი პროექტის სხვადასხვა მახასიათებლებზე, მაშინ შერწყმის კონფლიქტის ალბათობა, ანუ ალბათობა იმისა, რომ ერთი და იგივე ფაილი/კლასი შეიცვალოს რამდენიმე დეველოპერმა ერთდროულად, მინიმალურია.

განმარტებები

თუ ახალი ოპერაციის „დაასხით არაყი მაგიდის ქვეშ“ დამატებისას, თქვენ უნდა იმოქმედოთ ლოგერზე, დალევისა და ჩამოსხმის ოპერაციაზე, მაშინ, როგორც ჩანს, პასუხისმგებლობები არასწორად იყოფა. რა თქმა უნდა, ეს ყოველთვის არ არის შესაძლებელი, მაგრამ უნდა ვეცადოთ, რომ ეს მაჩვენებელი შევამციროთ.

4) ბიზნეს ლოგიკის შესახებ დამაზუსტებელი კითხვის დასმისას (დეველოპერისგან ან მენეჯერისგან), თქვენ შედიხართ მკაცრად ერთ კლასში/ფაილში და მხოლოდ იქიდან იღებთ ინფორმაციას.

განმარტებები

ფუნქციები, წესები ან ალგორითმები იწერება კომპაქტურად, თითოეული ერთ ადგილას და არ არის მიმოფანტული დროშებით კოდის სივრცეში.

5) დასახელება გასაგებია.

განმარტებები

ჩვენი კლასი ან მეთოდი პასუხისმგებელია ერთ რამეზე და პასუხისმგებლობა აისახება მის სახელზე

AllManagersManagerService - სავარაუდოდ ღმერთის კლასი
LocalPayment - ალბათ არა

ფორმალიზმი 3. Occam-პირველი განვითარების მეთოდოლოგია.

დიზაინის დასაწყისში მაიმუნმა არ იცის და არ გრძნობს პრობლემის გადაჭრის ყველა დახვეწილობას და შეუძლია შეცდომა დაუშვას. შეცდომის დაშვება შეგიძლიათ სხვადასხვა გზით:

• გახადეთ ობიექტები ძალიან დიდი სხვადასხვა პასუხისმგებლობების შერწყმით
• ხელახალი ჩარჩო ერთი პასუხისმგებლობის სხვადასხვა ტიპებად დაყოფით
• არასწორად განსაზღვრეთ პასუხისმგებლობის საზღვრები

მნიშვნელოვანია გვახსოვდეს წესი: „ჯობია დიდი შეცდომა დაუშვა“ ან „თუ დარწმუნებული არ ხარ, არ გაყო იგი“. თუ, მაგალითად, თქვენი კლასი შეიცავს ორ პასუხისმგებლობას, მაშინ ის მაინც გასაგებია და შეიძლება დაიყოს ორად კლიენტის კოდის მინიმალური ცვლილებებით. შუშის ნატეხებიდან შუშის აწყობა, როგორც წესი, უფრო რთულია კონტექსტის გავრცელების გამო რამდენიმე ფაილზე და კლიენტის კოდში საჭირო დამოკიდებულების არარსებობის გამო.

დროა მას დღე ვუწოდოთ

SRP-ის სფერო არ შემოიფარგლება OOP და SOLID-ით. ის ეხება მეთოდებს, ფუნქციებს, კლასებს, მოდულებს, მიკროსერვისებსა და სერვისებს. ეს ეხება როგორც "figax-figax-and-prod" და "rocket-science" განვითარებას, რაც სამყაროს ყველგან უკეთესს ხდის. თუ დაფიქრდებით, ეს თითქმის ყველა ინჟინერიის ფუნდამენტური პრინციპია. მექანიკური ინჟინერია, კონტროლის სისტემები და, მართლაც, ყველა რთული სისტემა აგებულია კომპონენტებისგან, და "ქვეფრაგმენტაცია" ართმევს დიზაინერებს მოქნილობას, "ზედმეტად ფრაგმენტაცია" ართმევს დიზაინერებს ეფექტურობას და არასწორი საზღვრები ართმევს მათ გონებას და სიმშვიდეს.

SRP არ არის გამოგონილი ბუნებით და არ არის ზუსტი მეცნიერების ნაწილი. ის არღვევს ჩვენს ბიოლოგიურ და ფსიქოლოგიურ შეზღუდვებს, ეს არის მხოლოდ გზა მაიმუნის ადამიანის ტვინის გამოყენებით რთული სისტემების კონტროლისა და განვითარებისთვის. ის გვეუბნება, როგორ დავშალოთ სისტემა. თავდაპირველი ფორმულირება მოითხოვდა ტელეპატიის საკმაოდ დიდ რაოდენობას, მაგრამ იმედი მაქვს, რომ ეს სტატია ასუფთავებს კვამლის ფარას.

წყარო: www.habr.com