SOLID, co je 5 principů objektově orientovaného programování

Pevné pevné geometrické tvary
výcvik
1

SOLID je zkratka odkazující na pět principů objektově orientovaného designu (OOD nebo OOP). Toto jsou pokyny, které mohou vývojáři použít k vytvoření softwaru, který se snadno spravuje, udržuje a rozšiřuje. Pochopení těchto konceptů z vás udělá lepšího vývojáře a pomůže vám vyhnout se problémům se správou softwaru. Co to znamená být dobrým programátorem?

Každý, kdo má nějaké zkušenosti s programováním softwaru, posuzuje softwarový kód napsaný ostatními pomocí parametrů úsudku na základě jejich kariérního postupu.

V průběhu své profesionální kariéry jsem znal mnoho vývojářů a viděl jsem tisíce řádků kódu, a když potřebuji zhodnotit dovednosti vývojáře, dívám se hlavně na dva faktory:

  • Jednoduchost čtení kódu;
  • Jak pravděpodobné je, že jejich kód bude fungovat a bude se vyvíjet v průběhu času.

Naštěstí existují určité základy nebo principy, které usnadňují lepší kódování.

zkratka SOLID znamená:
S: zásada jediné odpovědnosti
O: princip otevřeno-zavřeno
L: Princip substituce Liskov
I: Princip segregace rozhraní
D: Princip inverze závislostí

Začněme tím, že se ponoříme do prvního principu SOLID, konkrétně do

Princip jediné odpovědnosti

Třída (nebo modul) by měla mít pouze jeden důvod ke změně, k vývoji.

Samotný koncept je velmi jednoduchý, ale k dosažení této jednoduchosti může být cesta implementace velmi komplikovaná. Třída by měla mít pouze jeden důvod ke změně.

Ale proč? 

Proč je tak důležité mít jen jeden důvod ke změně?

Například pokud existují dva různé důvody pro změnu, je možné, že by dva různé týmy mohly pracovat na stejném kódu ze dvou různých důvodů. Každý bude muset implementovat své vlastní řešení, které by v případě kompilovaného jazyka (například C ++, C # nebo Java) mohlo vést k modulům, které nejsou kompatibilní s jinými týmy nebo jinými částmi aplikace.

Dalším příkladem, pokud používáte interpretovaný jazyk, bude pravděpodobně nutné znovu otestovat stejnou třídu nebo modul z různých důvodů. To znamená více práce, času a úsilí o kontrolu kvality.

Identifikace jediné funkce, kterou by třída nebo modul měly mít, je mnohem složitější než pouhé prohlížení kontrolního seznamu pro spuštění testů. 

Zkusme ale myslet z méně technického hlediska, tedy zkusme analyzovat uživatele naší třídy nebo modulu, tedy to, kdo je bude používat. Základním aspektem, který si musíme vždy pamatovat, je skutečnost, že uživatelé aplikace nebo systému, který vyvíjíme a kterým je obsluhován konkrétní modul, budou ti, kteří požadují jeho úpravy. Obsluhovaní požádají o změnu třídy nebo modulu. 

Několik příkladů modulů a jejich použití:

  • Modul údržby: uživatele tvoří správci databází a softwaroví architekti.
  • Modul hlášení: uživatel se skládá z administrativních pracovníků, účetních a výroby.
  • Modul výpočtu plateb pro systém správy mezd: mezi uživatele mohou patřit právníci, manažeři a účetní.
  • Modul pro vyhledávání textu pro systém správy knihoven: uživatele může zastupovat knihovník nebo návštěvníci a zákazníci samotné knihovny.

Pokud je tedy prvním krokem hledání herců nebo herce, který má roli partnera s modulem, může být obtížné sdružovat jednotlivce se všemi rolemi. V malé společnosti může jedna osoba hrát více rolí, zatímco ve velké společnosti může existovat více lidí, kteří mají jednu roli. 

Zdá se rozumnější identifikovat role spíše než lidi nebo uživatele.

Proto:

  • uživatel softwarového systému definuje důvody změny;
  • odpovědnost je skupina funkcí, která uspokojuje potřeby konkrétního aktéra, tj. uživatele systému;
  • aktéři, uživatel se stává zdrojem změn pro řadu funkcí, které musí uspokojovat potřeby uživatele;
  • vývoj potřeb uživatelů, řídí vývoj funkčnosti;

SOLIDNÍ principy

Podívejme se na několik příkladů

Předpokládejme, že máme třídu Book, která zapouzdřuje koncept knihy a její funkčnost.

třídní kniha {

    funkce getTitle () {

        návrat „Skvělá kniha“;

    }

    funkce getAuthor () {

        návrat „Alessandro Baricco“;

    }

    funkce nextpage () {

        // další strana

    }

    funkce printCurrentPage () {

        echo „obsah aktuální stránky“;

    }

}

To je velmi normální třída. Máme knihu a třída nám může dát název, může nám dát autora a může jít dál. Nakonec je také schopen tisknout aktuální stránku na obrazovce. 

Existuje však malý problém. 

Přemýšlíte o aktérech zapojených do správy objektu Book, kdo by to mohl být? 

Můžeme zde snadno myslet na dva různé herce: Správa knih (jako knihovník) A Mechanismus předávání údajů (například to, jak chceme uživateli doručit obsah: na obrazovce, grafické uživatelské rozhraní, pouze textové uživatelské rozhraní, možná tisk). 

Máme tedy dva velmi odlišné aktéry, kteří interagují s třídou.

Stručně řečeno, tato třída je kombinací:

  • obchodní logika s 
  • prezentace 

to může být problém, protože to porušuje zásadu jediné odpovědnosti (SRP). 

Jak se můžeme změnit, jak můžeme vylepšit tento kodex tak, aby respektoval zásadu jediné odpovědnosti?

Podívejte se na následující kód:

třídní kniha {

    funkce getTitle () {

        návrat „Oceano Mare“;

    }

    funkce getAuthor () {

        návrat „Alessandro Baricco“;

    }

    funkce otočit stránku () {

        // další strana

    }

    funkce getCurrentPage () {

        echo „obsah aktuální stránky“;

    }

}

tiskárna rozhraní {

    funkce printPage ($ page);

}

třída StampaLibro implementuje tiskárnu {

    funkce printPages ($ page) {

        echo $ page;

    }

}

 

třída HtmlPrinter implementuje tiskárnu {

    funkce printPages ($ page) {

        ozvěna ' '. $ stránka. '' ';

    }

}

Tento velmi jednoduchý příklad ukazuje, jak oddělit prezentaci od obchodní logiky, a v souladu se SRP nabízí velké výhody ve flexibilitě našeho projektu.

Podívejme se na další příklad:

Příklad podobný výše uvedenému je, když objekt může uložit a načíst se z prezentace.

třídní kniha {

    funkce getTitle () {

        návrat „Oceano Mare“;

    }

    funkce getAuthor () {

        návrat „Alessandro Baricco“;

    }

    funkce otočit stránku () {

        // další strana

    }

    funkce getCurrentPage () {

        vrátit "obsah aktuální stránky";

    }

    funkce save () {

        $ název souboru = '/ documents /'. $ this-> getTitolo (). „-“. $ this-> getAuthor ();

        file_put_contents ($ název souboru, serializace ($ toto));

    }

}

Stejně jako dříve můžeme i zde identifikovat různé herce Správa knih (jako knihovník) A Vytrvalost. Kdykoli chceme změnit způsob, jakým procházíme ze stránky na stránku, musíme změnit tuto třídu. Můžeme mít několik důvodů pro změnu.

třídní kniha {

    funkce getTitle () {

        návrat „Oceano Mare“;

    }

    funkce getAuthor () {

        návrat „Alessandro Baricco“;

    }

    funkce otočit stránku () {

        // další strana

    }

    funkce getCurrentPage () {

        vrátit "obsah aktuální stránky";

    }

}

třída SimpleFilePersistence {

    uložení funkce (Book $ book) {

        $ název souboru = '/ documents /'. $ book-> getTitle (). „-“. $ book-> getAuthor ();

        file_put_contents ($ název souboru, serializace ($ kniha));

    }

}

Přesunutí operace vytrvalosti do jiné třídy bude jasně oddělit odpovědnosti a my si budeme moci vyměňovat metody vytrvalosti bez ovlivnění naší třídy Book. Například implementace třídy DatabasePersistence by byla triviální a naše obchodní logika postavená na knižních operacích se nezmění.

Pokračujte ve čtení druhého principu Otevřeno / Zavřeno ->

Komentář 1

Zanechat komentář

Il tuo indirizzo email non Sara pubblicato. I campi sono obbligatori contrassegnati *

liskovův princip
výcvik
Princip substituce Liskov, třetí princip SOLID

Podřízené třídy by nikdy neměly ovlivňovat nebo měnit definice typů nadřazené třídy. Koncept tohoto principu představila Barbara Liskov na hlavní konferenci z roku 1987 a následně publikovala v článku společně s Jannette Wing v roce 1994. Jejich původní definice…

google marketingové trendy
výcvik
Jak používat Google Trends pro marketing v reálném čase

Jedním z největších problémů, s nimiž se společnosti v roce 2020 setkaly, bylo pochopení toho, ve kterých produktových odvětvích diverzifikovat své podnikání: ve skutečnosti většina průmyslových odvětví utrpěla těžké následky, což firmám téměř znemožňuje proniknout do nich, zejména jako nový hráč. Velmi málo výrobních odvětví ...

strategie business intelligence
metody
Strategie pro úspěšné Business Intelligence

Budování úspěšné strategie pro vaši Business Intelligence začíná správným viděním cílů. Níže uvádíme několik základních bodů. Posouzení současné situace Bylo by velkou chybou tento aspekt podceňovat. Vyhodnocení současné situace znamená analýzu procesů, struktur ...