{"id":34828,"date":"2019-10-31T22:00:38","date_gmt":"2019-10-31T19:00:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya\/"},"modified":"2019-10-31T22:00:38","modified_gmt":"2019-10-31T19:00:38","slug":"single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya","title":{"rendered":"Single Responsibility Principle. Not as simple as it seems.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Single Responsibility Principle. Not as simple as it seems.\" src=\"\/wp-content\/uploads\/2019\/06\/5b253ff55e3c97b6baf5f7a7ae7f3b98.JPG\" style=\"display:block;margin: 0 auto;\" \/> Het enkelvoudige verantwoordelijkheidsprincipe, ook wel het principe van enkele verantwoordelijkheid genoemd,<br \/>\nis ook het principe van enkele veranderlijkheid \u2014 een zeer lastig te begrijpen kwestie en een zenuwachtig onderwerp tijdens een programmeurssollicitatie. <\/p>\n<p><\/p>\n<p>Mijn eerste serieuze kennismaking met dit principe vond plaats aan het begin van het eerste jaar, toen we als jonge en onervaren studenten naar het bos werden gebracht, om van larven echte studenten te maken.<\/p>\n<p><\/p>\n<p>In het bos verdeelden we ons in groepen van 8-9 personen en organiseerden we een wedstrijd \u2014 welke groep het snelst een fles vodka opdronk, op voorwaarde dat de eerste persoon van de groep de vodka in een glas inschenkt, de tweede drinkt en de derde een hapje neemt. De deelnemer die zijn taak voltooit, gaat achteraan in de rij staan. <\/p>\n<p><\/p>\n<p>Een situatie waarin de grootte van de rij deelbaar was door drie, was een goede implementatie van SRP.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex> <\/p>\n<h2 id=\"opredelenie-1-edinaya-otvetstvennost\">Definitie 1. Enkele verantwoordelijkheid.<\/h2>\n<p><\/p>\n<p>De offici\u00eble definitie van het enkele verantwoordelijkheidsprincipe (SRP) stelt dat elk object zijn eigen verantwoordelijkheid en bestaansreden heeft, en dat deze verantwoordelijkheid slechts \u00e9\u00e9n is.<\/p>\n<p><\/p>\n<p>Laten we het object &#171;Drankerd&#187; beschouwen (<strong>Tippler<\/strong>).<br \/>\nOm het principe van SRP te volgen, verdelen we de verantwoordelijkheden onder drie personen: <\/p>\n<p><\/p>\n<ul>\n<li>Iemand schenkt in (<strong>PourOperation<\/strong>)<\/li>\n<li>Iemand drinkt (<strong>DrinkUpOperation<\/strong>)<\/li>\n<li>Iemand neemt een hap (<strong>TakeBiteOperation<\/strong>)<\/li>\n<\/ul>\n<p><\/p>\n<p>Elke deelnemer aan het proces is verantwoordelijk voor \u00e9\u00e9n component van het proces, dat wil zeggen dat hij een atomische verantwoordelijkheid heeft \u2014 drinken, inschenken of eten. <\/p>\n<p><\/p>\n<p>Tippler is op zijn beurt een facade voor deze operaties:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">class Tippler {\n    \/\/...\n    void Act(){\n        _pourOperation.Do() \/\/ inschenken\n        _drinkUpOperation.Do() \/\/ drinken\n        _takeBiteOperation.Do() \/\/ hap nemen\n    }\n}<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Single Responsibility Principle. Not as simple as it seems.\" src=\"\/wp-content\/uploads\/2019\/06\/8d591a474e3555edfee3ffebc28d079b.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4 id=\"zachem\">Waarom?<\/h4>\n<p><\/p>\n<p>De programmeur schrijft code voor de aapmens, en de aapmens is onoplettend, dom en haastig. Hij kan ongeveer 3 tot 7 termen tegelijkertijd begrijpen en onthouden.<br \/>\nIn het geval van de Tippler zijn er drie termen. Maar als we de code in \u00e9\u00e9n blok schrijven, zullen er handen, glassen, vechtpartijen en eindeloze discussies over politiek in verschijnen. En dit alles zal zich in het lichaam van \u00e9\u00e9n methode bevinden. Ik weet zeker dat je zo'n code in je praktijk hebt gezien. Geen humane uitdaging voor de psyche.<\/p>\n<p><\/p>\n<p>Aan de andere kant is de mens-aap ingesteld op het modelleren van objecten uit de echte wereld in zijn hoofd. In zijn verbeelding kan hij ze tegen elkaar aan laten botsen, nieuwe objecten maken en ze op dezelfde manier weer uit elkaar halen. Stel je een oud automodel voor. Je kunt je inbeelden dat je de deur opent, het deurpaneel losdraait en de mechanismen van de raamschakelaars ziet, waarin tandwielen zitten. Maar je kunt niet alle componenten van de auto tegelijk zien, in \u00e9\u00e9n &#171;lijsting&#187;. Tenminste, de &#171;mens-aap&#187; kan dat niet.<\/p>\n<p><\/p>\n<p>Daarom decomponeren programmeurs complexe mechanismen in een set van minder complexe en functionele elementen. Echter, decomponeren kan op verschillende manieren: bij veel oude auto's komt het luchtkanaal uit in de deur, terwijl bij moderne auto's een elektronische storing van het slot voorkomt dat de motor start, wat lastig is bij het repareren.<\/p>\n<p><\/p>\n<p>Dus, <strong>SRP is een principe dat uitlegt HOE te decomponeren, dat wil zeggen waar de scheidingslijn moet liggen.<\/strong>. <\/p>\n<p><\/p>\n<p>Hij zegt dat je moet decomponeren volgens het principe van &#171;verantwoordelijkheidsscheiding&#187;, dat wil zeggen volgens de taken van bepaalde objecten.<\/p>\n<p>\n<img decoding=\"async\" alt=\"Single Responsibility Principle. Not as simple as it seems.\" src=\"\/wp-content\/uploads\/2019\/06\/b1980c3dc9742b921eb818f14fe3527e.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Laten we terugkeren naar de drinker en de voordelen die de mens-apen krijgt bij het decomponeren: <\/p>\n<p><\/p>\n<ul>\n<li>De code is op elk niveau glashelder.<\/li>\n<li>Code kan door meerdere programmeurs tegelijkertijd worden geschreven (iedereen schrijft een apart element).<\/li>\n<li>Automatische tests worden eenvoudiger \u2014 hoe eenvoudiger het element, hoe gemakkelijker het te testen is.<\/li>\n<li>Er ontstaat samenstelling van code \u2014 je kunt vervangen <strong>DrinkUpOperation<\/strong> door een operatie waarin de drinker vloeistof onder de tafel giet. Of vervang de schenking door een operatie waarin je wijn en water of wodka en bier mengt. Afhankelijk van de eisen van het bedrijf kun je alles doen, zonder de code van de methode aan te raken. <strong>Tippler.Act<\/strong>. <\/li>\n<li>Uit deze operaties kun je de vreters samenstellen (door alleen gebruik te maken van <strong>TakeBitOperation<\/strong>), de alcoholist (door alleen <strong>DrinkUpOperation<\/strong> rechtstreeks uit de fles) en voldoen aan veel andere bedrijfsvereisten.<\/li>\n<\/ul>\n<p><\/p>\n<p><em>(Oh, kennelijk is dit al het OCP-principe, en heb ik de verantwoordelijkheid van deze post geschonden) <\/em><\/p>\n<p><\/p>\n<p>En natuurlijk zijn er nadelen: <\/p>\n<p><\/p>\n<ul>\n<li>Je zult meer typen moeten cre\u00ebren. <\/li>\n<li>De drinker zal voor het eerst een paar uur later drinken dan hij zou kunnen.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"opredelenie-2-edinaya-izmenchivost\">Definitie 2. Eenduidige wijzigbaarheid.<\/h2>\n<p><\/p>\n<p>Sta me toe, heren! De klasse van de drankerd heeft ook een duidelijke verantwoordelijkheid \u2014 hij drinkt! En \u00fcberhaupt, het woord &#171;verantwoordelijkheid&#187; is een uiterst vaag begrip. Iemand is verantwoordelijk voor het lot van de mensheid, en iemand anders is verantwoordelijk voor het weer oprichten van omgevallen pingu\u00efns op de pool.<\/p>\n<p><\/p>\n<p>Laten we twee implementaties van de drinker bekijken. De eerste, hierboven genoemd, bevat drie klassen \u2014 inschenken, drinken en snacken.<\/p>\n<p><\/p>\n<p>De tweede is geschreven volgens de methodologie &#171;Vooruit en alleen vooruit&#187; en bevat alle logica binnen de methode. <strong>Act<\/strong>:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">\/\/\u041d\u0435 \u0442\u0440\u0430\u0442\u044c\u0442\u0435 \u0432\u0440\u0435\u043c\u044f  \u043d\u0430 \u0438\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u044d\u0442\u043e\u0433\u043e \u043a\u043b\u0430\u0441\u0441\u0430. \u041b\u0443\u0447\u0448\u0435 \u0441\u044a\u0435\u0448\u044c\u0442\u0435 \u043f\u0435\u0447\u0435\u043d\u044c\u043a\u0443\n\u0441lass BrutTippler {\n   \/\/...\n   void Act(){\n        \/\/ \u043d\u0430\u043b\u0438\u0432\u0430\u0435\u043c\n    if(!_hand.TryDischarge(from:_bottle, to:_glass, size:_glass.Capacity))\n        throw new OverdrunkException();\n\n    \/\/ \u0432\u044b\u043f\u0438\u0432\u0430\u0435\u043c\n    if(!_hand.TryDrink(from: _glass,  size: _glass.Capacity))\n        throw new OverdrunkException();\n\n    \/\/\u0417\u0430\u043a\u0443\u0441\u044b\u0432\u0430\u0435\u043c\n    for(int i = 0; i&lt; 3; i++){\n        var food = _foodStore.TakeOrDefault();\n        if(food==null)\n            throw new FoodIsOverException();\n\n        _hand.TryEat(food);\n    }\n   }\n}<\/code><\/pre>\n<p><\/p>\n<p>Deze twee klassen zien er vanuit het perspectief van een externe waarnemer absoluut identiek uit en vervullen de enkele verantwoordelijkheid &#171;drinken&#187;. <\/p>\n<p><\/p>\n<p>Wat een g\u00eanant<\/p>\n<p><\/p>\n<p>Dan duiken we het internet in en ontdekken een andere definitie van SRP \u2014 Het Principe van Eenzelfde Veranderlijkheid (Single Changeability Principle).<\/p>\n<p><\/p>\n<p>SCP stelt dat &#171;<strong>Een module heeft \u00e9\u00e9n en alleen \u00e9\u00e9n reden voor verandering<\/strong>&#171;. Dat wil zeggen &#171;Verantwoordelijkheid is een aanleiding voor verandering&#187;. <\/p>\n<p><\/p>\n<p><em>(Het lijkt erop dat de jongens die de oorspronkelijke definitie bedachten, overtuigd waren van de telepathische vermogens van de mens-aap)<\/em><\/p>\n<p><\/p>\n<p>Nu valt alles op zijn plaats. We kunnen de inschenk-, drink- en snackprocedures afzonderlijk wijzigen, en binnen de drinker kunnen we alleen de volgorde en samenstelling van de operaties veranderen, bijvoorbeeld door de snack voor het drinken te verplaatsen of het voorlezen van een toost toe te voegen.<\/p>\n<p><\/p>\n<p>In de aanpak &#171;Vooruit en alleen vooruit&#187; verandert alles wat kan alleen binnen de methode. <strong>Act<\/strong>. Dit kan leesbaar en effectief zijn als er weinig logica is en deze zelden verandert, maar vaak eindigt dit in verschrikkelijke methoden van 500 regels elk, met meer if-structuren dan nodig is voor Rusland om lid te worden van de NAVO. <\/p>\n<p><\/p>\n<h2 id=\"opredelenie-3-lokalizaciya-izmeneniy\">Definitie 3. Lokalisatie van wijzigingen.<\/h2>\n<p><\/p>\n<p>Drankers begrijpen vaak niet waarom ze in een vreemd appartement zijn wakker geworden, of waar hun mobiel is. Het is tijd om gedetailleerde logging toe te voegen.<\/p>\n<p><\/p>\n<p>Laten we de logging beginnen met het inschenken:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">class PourOperation: IOperation{\n    PourOperation(ILogger log \n\/*....*\/){\n\/*...*\/}\n    \/\/...\n    void Do(){\n        _log.Log($\"Voor inschenken met {_hand} en {_bottle}\");\n        \/\/ Drink business logic ...\n        _log.Log($\"Na inschenken met {_hand} en {_bottle}\");\n    }\n}<\/code><\/pre>\n<p><\/p>\n<p>door het te encapsuleren in <strong>PourOperation<\/strong>, we acted wisely in terms of responsibility and encapsulation, but now we have a dilemma with the variability principle. Besides the operation itself, which can change, the logging itself is also becoming variable. We will need to separate it and create a special logger for the pouring operation:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">interface IPourLogger{\n    void LogBefore(IHand, IBottle){}\n    void LogAfter(IHand, IBottle){}\n    void OnError(IHand, IBottle, Exception){}\n}\n\nclass PourOperation: IOperation{\n    PourOperation(IPourLogger log \/*....*\/){\/*...*\/}\n    \/\/...\n    void Do(){\n        _log.LogBefore(_hand, _bottle);\n        try{\n             \/\/... business logic\n             _log.LogAfter(_hand, _bottle);\n        }\n        catch(exception e){\n            _log.OnError(_hand, _bottle, e);\n        }\n    }\n}<\/code><\/pre>\n<p><\/p>\n<p>The attentive reader will notice that <strong>LogAfter<\/strong>, <strong>LogBefore<\/strong> en <strong>OnError<\/strong> can also change separately, and in analogy with previous actions, it will create three classes: <strong>PourLoggerBefore<\/strong>, <strong>PourLoggerAfter<\/strong> en <strong>PourErrorLogger<\/strong>.<\/p>\n<p><\/p>\n<p>Recalling that there are three operations for the drinker, we end up with nine logging classes. In total, the drinker consists of 14 (!!!) classes.<\/p>\n<p><\/p>\n<p>Hyperbole? Hardly! The person-monkey with a decomposition grenade will shatter the 'pourer' into a decanter, glass, pouring operators, water supply service, physical model of molecule collisions, and next quarter will try to untangle dependencies without global variables. And believe me, he won't stop.<\/p>\n<p><\/p>\n<p>Juist op dit punt komen velen tot de conclusie dat SRP sprookjes zijn uit roze koninkrijken, en besluiten naar hun waarheid te gaan\u2026<\/p>\n<p><\/p>\n<p>\u2026 and never learn about the existence of the third definition of SRP: <\/p>\n<p><\/p>\n<p>&#171;Het principe van enkele verantwoordelijkheid stelt dat <strong>similar things that change should be kept in one place<\/strong>&#171;. of \u201c<strong>Things that change together should be kept in one place.<\/strong>\u201d<\/p>\n<p><\/p>\n<p>That is, if we change the logging of an operation, we must change it in one place.<\/p>\n<p><\/p>\n<p>Dit is een heel belangrijk punt \u2014 aangezien alle eerdere uitleg over SRP zei dat je types moet splitsen tot ze zijn gesplitst, dat wil zeggen dat het een &#171;bovenlimiet&#187; op de grootte van het object legde, en nu praten we nu ook over een &#171;ondergrens&#187;. Met andere woorden, <strong>SRP vereist niet alleen dat je &#171;splitsen tot het niet meer kan&#187;, maar ook dat je niet te ver gaat \u2014 &#171;neem niet gescheiden dingen uit elkaar&#187;<\/strong>. This is a great battle of Occam's razor against the monkey-man!<\/p>\n<p>\n<img decoding=\"async\" alt=\"Single Responsibility Principle. Not as simple as it seems.\" src=\"\/wp-content\/uploads\/2019\/06\/2e349a5b119a511d716341f3f6725844.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Now the drinker should find it easier. Besides not having to split the IPourLogger logger into three classes, we can also combine all the loggers into one type:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">class OperationLogger{\n    public OperationLogger(string operationName){\n\/*..*\/}\n    public void LogBefore(object[] args){\n\/*...*\/}\n    public void LogAfter(object[] args){\n\/*..*\/}\n    public void LogError(object[] args, exception e){\n\/*..*\/}\n}<\/code><\/pre>\n<p><\/p>\n<p>En als we een vierde type operatie zouden toevoegen, is de logging daarvoor al gereed. De code van de operaties zelf is schoon en vrij van infrastructuurgeluid.<\/p>\n<p><\/p>\n<p>Als resultaat hebben we 5 klassen om de taak van het drinken op te lossen:<\/p>\n<p><\/p>\n<ul>\n<li>Invoeren van de operatie<\/li>\n<li>Uitvoeren van de operatie<\/li>\n<li>Eten van de operatie<\/li>\n<li>Logger<\/li>\n<li>Facade van de drinker<\/li>\n<\/ul>\n<p><\/p>\n<p>Elke klasse is strikt verantwoordelijk voor \u00e9\u00e9n functionaliteit en heeft \u00e9\u00e9n reden voor wijziging. Alle vergelijkbare regels voor wijziging liggen dicht bij elkaar. <\/p>\n<p>\n<b class=\"spoiler_title\">Voorbeeld uit het echte leven<\/b><\/p>\n<p>Een keer schreven we een service voor automatische registratie van B2B-klanten. En er verscheen een GOD-methode van 200 regels met zulke inhoud:<\/p>\n<p><\/p>\n<ul>\n<li>Ga naar 1C en maak een rekening aan<\/li>\n<li>Neem deze rekening mee naar de betalingsmodule en registreer het daar<\/li>\n<li>Controleer of er geen account met deze rekening is aangemaakt in het hoofdsysteem <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/nl\/server\/dts-dronten\/\"   title=\"de server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"2485\">de server<\/a><\/li>\n<li>Maak een nieuw account aan<\/li>\n<li>Voeg het registratie resultaat in de betalingsmodule en het 1C-nummer toe aan de registratie resultaten service<\/li>\n<li>Voeg informatie over het account aan deze tabel toe<\/li>\n<li>Cre\u00eber een puntnummer voor deze klant in de service voor punten. Stuur het rekeningnummer naar deze service.<\/li>\n<\/ul>\n<p><\/p>\n<p>En in deze lijst stonden nog ongeveer 10 zakelijke operaties met vreselijke onderlinge afhankelijkheid. Het rekeningobject was bijna voor iedereen nodig. Het punt-id en de naam van de klant waren in de helft van de oproepen nodig.<\/p>\n<p><\/p>\n<p>Na een uur refactoren konden we de infrastructuurcode en sommige nuances van het werken met de account in aparte methoden\/klassen scheiden. De GOD-methode was lichter, maar er bleven 100 regels code over die zich maar niet wilden ontwarren. <\/p>\n<p><\/p>\n<p>Pas na enkele dagen kwam het besef dat de essentie van deze &#171;verlichte&#187; methode een bedrijfsalgoritme was. En dat de oorspronkelijke beschrijving van de specificatie behoorlijk complex was. En precies het proberen om deze methode in stukken te splitsen, zou een schending van SRP zijn, en niet andersom. <\/p>\n<p><\/p>\n<h2 id=\"formalizm\">Formalisme.<\/h2>\n<p><\/p>\n<p>Het is tijd om onze drinker met rust te laten. Veeg de tranen weg - we zullen ooit naar hem terugkeren. Maar nu willen we de kennis uit dit artikel formaliseren. <\/p>\n<p><\/p>\n<h4 id=\"formalizm-1-opredelenie-srp\">Formalisme 1. Definitie van SRP<\/h4>\n<p><\/p>\n<ol>\n<li>Scheiding van elementen zodat elk van hen verantwoordelijk is voor \u00e9\u00e9n ding.<\/li>\n<li>Verantwoordelijkheid wordt gedefinieerd als 'reden voor verandering'. Dit betekent dat elk element slechts \u00e9\u00e9n reden voor verandering heeft, in termen van zakelijke logica.<\/li>\n<li>Potenti\u00eble wijzigingen in de bedrijfslogica moeten worden gelokaliseerd. Wijzigbare gesynchroniseerde elementen moeten naast elkaar staan.<\/li>\n<\/ol>\n<p><\/p>\n<h4 id=\"formalizm-2-neobhodimye-kriterii-samoproverki\">Formalism 2. Vereiste zelfcontrolecriteria.<\/h4>\n<p><\/p>\n<p>Ik ben niet voldoende criteria voor de uitvoering van SRP tegengekomen. Maar er zijn noodzakelijke voorwaarden:<\/p>\n<p><\/p>\n<p>1) Stel jezelf de vraag \u2014 wat doet deze klasse\/methode\/module\/service. Je moet het kunnen beantwoorden met een eenvoudige definitie. (bedankt <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/brightori\/\" class=\"user_link\">Brightori<\/a><\/noindex> )<\/p>\n<p>\n<b class=\"spoiler_title\">verklaringen<\/b><\/p>\n<p>Toch is het soms erg moeilijk om een eenvoudige definitie te vinden. <\/p>\n<p><\/p>\n<p>2) Het fixen van een bepaald bug of het toevoegen van een nieuwe functie raakt het minimale aantal bestanden\/klassen. Bij voorkeur \u2014 \u00e9\u00e9n. <\/p>\n<p>\n<b class=\"spoiler_title\">verklaringen<\/b><\/p>\n<p>Aangezien de verantwoordelijkheid (voor de functie of bug) gecapsuleerd is in \u00e9\u00e9n bestand\/klasse, weet je precies waar je moet zoeken en wat je moet aanpassen. Bijvoorbeeld: de functie voor het wijzigen van de uitvoer van de logging van operaties zal alleen de logger vereisen te wijzigen. Je hoeft niet door de rest van de code te rennen. <\/p>\n<p><\/p>\n<p>Een ander voorbeeld \u2014 het toevoegen van een nieuwe UI-controle die vergelijkbaar is met eerdere. Als dit je dwingt 10 verschillende entiteiten en 15 verschillende converters toe te voegen \u2014 lijkt het erop dat je 'overgedimensioneerd' hebt.<\/p>\n<p><\/p>\n<p>3) Als verschillende ontwikkelaars aan verschillende functies van je project werken, is de kans op een merge-conflict, dat wil zeggen de kans dat hetzelfde bestand\/klasse door meerdere ontwikkelaars tegelijk wordt gewijzigd, minimaal.<\/p>\n<p>\n<b class=\"spoiler_title\">verklaringen<\/b><\/p>\n<p>Als je bij het toevoegen van een nieuwe operatie 'Wodka onder de tafel gieten' de logger, de drink- en gietoperatie moet be\u00efnvloeden, lijkt het erop dat de verantwoordelijkheden krom zijn verdeeld. Dit is niet altijd mogelijk, maar het is belangrijk om te proberen deze maat te verlagen. <\/p>\n<p><\/p>\n<p>4) Bij een verduidelijkende vraag over de bedrijfslogica (van een ontwikkelaar of manager) kijk je strikt in \u00e9\u00e9n klasse\/bestand en krijg je informatie alleen daarvandaan.<\/p>\n<p>\n<b class=\"spoiler_title\">verklaringen<\/b><\/p>\n<p>Functies, regels of algoritmes zijn compact geschreven, elk op \u00e9\u00e9n plaats, en niet verspreid over de code met vlaggen.<\/p>\n<p><\/p>\n<p>5) Naamgeving is duidelijk.<\/p>\n<p>\n<b class=\"spoiler_title\">verklaringen<\/b><\/p>\n<p>Onze klasse of methode is verantwoordelijk voor iets eenduidigs, en de verantwoordelijkheid is weerspiegeld in de naam.<\/p>\n<p><\/p>\n<p>AllManagersManagerService \u2014 waarschijnlijk een God-klasse.<br \/>\nLocalPayment \u2014 waarschijnlijk niet. <\/p>\n<p><\/p>\n<h4 id=\"formalizm-3-metodika-razrabotki-okkama-first\">Formalisme 3. Methode voor ontwikkeling 'Ockham-first'.<\/h4>\n<p><\/p>\n<p>Aan het begin van de ontwerpfase weet de mens-aap niet alle fijne kneepjes van het op te lossen probleem en kan hij een fout maken. Er zijn verschillende manieren om fouten te maken:<\/p>\n<p><\/p>\n<ul>\n<li>Te grote objecten maken door verschillende verantwoordelijkheden samen te voegen.<\/li>\n<li>Verdeeld, de unieke verantwoordelijkheid splitsen in veel verschillende soorten.<\/li>\n<li>Onjuist de grenzen van verantwoordelijkheden defini\u00ebren.<\/li>\n<\/ul>\n<p><\/p>\n<p>Het is belangrijk om de regel te onthouden: 'fouten maken is beter in de grote richting', of 'twijfel je \u2013 splitst niet'. Als bijvoorbeeld je klasse twee verantwoordelijkheden samenbrengt, is het nog steeds begrijpelijk en kan deze worden gesplitst in twee met minimale veranderingen in de clientcode. Het samenstellen van een glas uit glasscherven is doorgaans ingewikkelder vanwege de verspreide context over meerdere bestanden en het ontbreken van de noodzakelijke afhankelijkheden in de clientcode. <\/p>\n<p><\/p>\n<h2 id=\"pora-zakruglyatsya\">Het is tijd om af te ronden.<\/h2>\n<p><\/p>\n<p>Het toepassingsgebied van SRP is niet beperkt tot OOP en SOLID. Het is toepasbaar op methoden, functies, klassen, modules, microservices en services. Het is van toepassing op zowel 'figaks-figaks-en-in-product' als 'rocket-science' ontwikkeling, en maakt de wereld overal een beetje beter. Als je erover nadenkt, is dit haast een fundamenteel principe van alle techniek. Werktuigbouwkunde, regelsystemen en eigenlijk alle complexe systemen zijn opgebouwd uit componenten, en 'onderdelen niet te splitsen' ontnemen de ontwerpers flexibiliteit, 'te veel splitsen' effici\u00ebntie, en onjuiste grenzen - rede en gemoedsrust. <\/p>\n<p>\n<img decoding=\"async\" alt=\"Single Responsibility Principle. Not as simple as it seems.\" src=\"\/wp-content\/uploads\/2019\/06\/b70fb2b0b87cf90d41462263e839902b.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>SRP is niet door de natuur uitgevonden en maakt geen deel uit van exacte wetenschappen. Het komt voort uit onze biologische en psychologische beperkingen. Het is gewoon een manier om complexe systemen te beheersen en te ontwikkelen met behulp van de menselijke geest. Het vertelt ons hoe we een systeem kunnen decomponeer. De oorspronkelijke formulering vereiste aanzienlijke telepathische vaardigheden, maar ik hoop dat dit artikel een beetje de rookgordijnen heeft opgehelderd.<\/p>\n<p>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/454290\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Single responsibility principle, \u043e\u043d \u0436\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f \u0435\u0434\u0438\u043d\u043e\u0439 \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u0438, \u043e\u043d \u0436\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f \u0435\u0434\u0438\u043d\u043e\u0439 \u0438\u0437\u043c\u0435\u043d\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u2014 \u043a\u0440\u0430\u0439\u043d\u0435 \u0441\u043a\u043e\u043b\u044c\u0437\u043a\u0438\u0439 \u0434\u043b\u044f \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u044f \u043f\u0430\u0440\u0435\u043d\u044c \u0438 \u0441\u0442\u043e\u043b\u044c \u043d\u0435\u0440\u0432\u043e\u0437\u043d\u044b\u0439 \u0432\u043e\u043f\u0440\u043e\u0441 \u043d\u0430 \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430. \u041f\u0435\u0440\u0432\u043e\u0435 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435 \u0437\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 \u044d\u0442\u0438\u043c \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u043e\u043c \u0441\u043e\u0441\u0442\u043e\u044f\u043b\u043e\u0441\u044c \u0434\u043b\u044f \u043c\u0435\u043d\u044f \u0432 \u043d\u0430\u0447\u0430\u043b\u0435 \u043f\u0435\u0440\u0432\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430, \u043a\u043e\u0433\u0434\u0430 \u043c\u043e\u043b\u043e\u0434\u044b\u0445 \u0438 \u0437\u0435\u043b\u0435\u043d\u044b\u0445 \u043d\u0430\u0441 \u0432\u044b\u0432\u0435\u0437\u043b\u0438 \u0432 \u043b\u0435\u0441, \u0447\u0442\u043e\u0431\u044b \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0438\u0437 \u043b\u0438\u0447\u0438\u043d\u043e\u043a \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u2014 \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0445. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26229,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-34828","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Single Responsibility Principle. \u041d\u0435 \u0442\u0430\u043a\u043e\u0439 \u043f\u0440\u043e\u0441\u0442\u043e\u0439, \u043a\u0430\u043a \u043a\u0430\u0436\u0435\u0442\u0441\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:38+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:38+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Single Responsibility Principle. Niet zo eenvoudig als het lijkt | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Single Responsibility Principle. \u041d\u0435 \u0442\u0430\u043a\u043e\u0439 \u043f\u0440\u043e\u0441\u0442\u043e\u0439, \u043a\u0430\u043a \u043a\u0430\u0436\u0435\u0442\u0441\u044f | ProHoster","og:url":"https:\/\/prohoster.info\/nl\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:38+00:00","article:modified_time":"2019-10-31T19:00:38+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34828","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 21:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:14:06","updated":"2026-02-09 21:46:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/34828","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=34828"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/34828\/revisions"}],"predecessor-version":[{"id":159767,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/34828\/revisions\/159767"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/26229"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=34828"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=34828"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=34828"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}