SZILÁRD, mi az objektum-orientált programozás 5 alapelve

Szilárd, szilárd geometriai ábrák
edzés
1

A SOLID egy rövidítés, amely az objektum-orientált tervezés öt elvére utal (OOD vagy OOP). Ezek olyan irányelvek, amelyekkel a fejlesztők könnyen kezelhető, karbantartható és bővíthető szoftvereket hozhatnak létre. Ezeknek a fogalmaknak a megértése jobb fejlesztővé tesz, és segít elkerülni a szoftverkezelési problémákat. Mit jelent jó programozónak lenni?

Bárki, aki rendelkezik valamilyen tapasztalattal a szoftver programozásában, megítéli a mások által írt szoftver kódot, karrierjük alapján megítélési paramétereket használva.

Szakmai pályafutásom során sok fejlesztőt ismertem, és több ezer sornyi kódot láttam, és amikor értékelnem kell egy fejlesztő képességeit, akkor főleg két tényezőt vizsgálok:

  • A kódolvasás egyszerűsége;
  • Mennyire valószínű, hogy kódjuk működik és fejlődik az idő múlásával.

Szerencsére vannak olyan alapismeretek vagy elvek, amelyek megkönnyítik a kódolás jobb fejlesztését.

a SOLID rövidítés a következőket jelenti:
S: az egyetlen felelősség elve
O: nyitott-zárt elv
L: Liskov helyettesítési elv
I: Az interfész elkülönítésének elve
D: A függőségek inverziójának elve

Kezdjük azzal, hogy elmélyüljünk az első SZILÁDD elvben, nevezetesen a

Egyetlen felelősség elve

Egy osztálynak (vagy modulnak) csak egy oka lehet a változásra, a fejlődésre.

Maga a koncepció nagyon egyszerű, de ennek az egyszerűségnek az elérése érdekében a megvalósítási út nagyon bonyolult lehet. Egy osztálynak csak egy oka lehet a váltásra.

De miért? 

Miért olyan fontos, hogy csak egy oka van a változásra?

Például, ha két különböző oka van a változtatásnak, elképzelhető, hogy két különböző csapat ugyanazon a kódon dolgozhat két különböző okból. Mindegyiknek meg kell valósítania a saját megoldását, amely egy lefordított nyelv (például C ++, C # vagy Java) esetén olyan modulokhoz vezethet, amelyek nem kompatibilisek más csapatokkal vagy az alkalmazás más részeivel.

Egy másik példa, ha értelmezett nyelvet használ, előfordulhat, hogy ugyanazon osztályt vagy modult különböző okokból újra kell tesztelnie. Ez több munkát, időt és erőfeszítést jelent a minőség-ellenőrzés érdekében.

Az osztály vagy modul egyetlen jellemzőjének azonosítása sokkal összetettebb, mint egyszerűen egy ellenőrzőlista megtekintése a tesztek futtatásához. 

De próbáljunk meg kevésbé technikai szempontból gondolkodni, vagyis próbáljuk meg elemezni az osztályunk vagy modulunk felhasználóját, azaz ki fogja használni. Alapvető szempont, amelyet mindig szem előtt kell tartanunk, az a tény, hogy az általunk fejlesztett alkalmazás vagy rendszer felhasználói, akiket egy adott modul szolgál ki, módosítást kérnek. A szolgálatot teljesítők kérni fogják az osztály vagy a modul megváltoztatását. 

Néhány példa a modulokra és azok használatára:

  • Karbantartási modul: a felhasználó adatbázis-adminisztrátorokból és szoftverépítészekből áll.
  • Jelentési modul: a felhasználó irodai dolgozókból, könyvelőkből és a termelésből áll.
  • Fizetési számítási modul bérszámfejtési rendszerhez: a felhasználók között lehetnek ügyvédek, vezetők és könyvelők.
  • Szövegkereső modul könyvtárkezelő rendszerhez: a felhasználót képviselheti a könyvtáros, vagy maga a könyvtár látogatói és vásárlói.

Tehát, ha az első lépés a szereplők vagy a színész megkeresése, akinek a modullal beszélgetőpartneri szerepe van, az egyének társítása az összes szerephez nehéz lehet. Egy kis társaságban egy ember több szerepet is játszhat, míg egy nagy társaságban több ember is lehet, akiknek egyetlen szerepük van. 

Ésszerűbbnek tűnik a szerepek azonosítása, nem pedig az emberek vagy a felhasználók.

Ezért:

  • a szoftverrendszer felhasználója meghatározza a változás okait;
  • a felelősség olyan funkciócsalád, amely kielégíti egy adott szereplő, vagyis a rendszerhasználó igényeit;
  • a szereplők, a felhasználó változik a funkciók családjában, amelynek meg kell felelnie a felhasználó igényeinek;
  • a felhasználói igények alakulása, irányítja a funkcionalitás fejlődését;

SZILÁRD elvek

Lássunk néhány példát

Tegyük fel, hogy van egy könyv osztályunk, amely összefoglalja a könyv fogalmát és annak funkcionalitását.

osztálykönyv {

    függvény getTitle () {

        visszatér egy „Nagy könyv”;

    }

    függvény getAuthor () {

        visszatér Alessandro Baricco;

    }

    function nextpage () {

        // következő oldal

    }

    függvény printCurrentPage () {

        echo „az aktuális oldal tartalma”;

    }

}

Ez egy nagyon normális osztály. Van egy könyvünk, és az osztály megadhatja a címet, megadhatja a szerzőt, és továbbléphetnek. Végül az aktuális oldal kinyomtatására is képes. 

Van azonban egy kis probléma. 

A Könyv objektum kezelésében részt vevő szereplőkre gondolva kik lehetnek? 

Könnyen gondolhatunk itt két különböző szereplőre: Könyvkezelés (mint a könyvtáros) És Adatbeküldési mechanizmus (például hogyan szeretnénk tartalmat eljuttatni a felhasználóhoz: képernyőn, grafikus felhasználói felület, csak szöveges felhasználói felület, esetleg nyomtatás). 

Ezért két nagyon különböző színész van interakcióban az osztállyal.

Dióhéjban ez az osztály keveréket alkot:

  • üzleti logika 
  • a prezentáció 

ez problémát jelenthet, mert sérti az egyetlen felelősség elvét (SRP). 

Hogyan változtathatunk, hogyan javíthatjuk ezt a kódexet, hogy tiszteletben tartsuk az egyetlen felelősség elvét?

Vessen egy pillantást a következő kódra:

osztálykönyv {

    függvény getTitle () {

        vissza az „Oceano Mare”;

    }

    függvény getAuthor () {

        visszatér Alessandro Baricco;

    }

    function turn page () {

        // következő oldal

    }

    függvény getCurrentPage () {

        echo „az aktuális oldal tartalma”;

    }

}

interfész nyomtató {

    függvény printPage ($ oldal);

}

osztályú StampaLibro nyomtatót hajt végre

    függvény printPages ($ page) {

        echo $ oldal;

    }

}

 

class HtmlPrinter megvalósítja a nyomtatót {

    függvény printPages ($ page) {

        visszhang ”. $ oldal. " ";

    }

}

Ez a nagyon egyszerű példa bemutatja, hogyan lehet elkülöníteni a prezentációt az üzleti logikától, és az SRP-vel összhangban nagy előnyökkel jár a projektünk rugalmasságában.

Nézzünk meg egy másik példát:

A fentihez hasonló példa, amikor egy objektum elmentheti és lekérheti magát a bemutatóból.

osztálykönyv {

    függvény getTitle () {

        vissza az „Oceano Mare”;

    }

    függvény getAuthor () {

        visszatér Alessandro Baricco;

    }

    function turn page () {

        // következő oldal

    }

    függvény getCurrentPage () {

        return "az aktuális oldal tartalma";

    }

    function save () {

        $ fájlnév = '/ dokumentumok /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();

        file_put_contents ($ fájlnév, sorosítás ($ this));

    }

}

Mint korábban, itt is azonosíthatunk különböző szereplőket Könyvkezelés (mint a könyvtáros) És Kitartás. Amikor meg akarjuk változtatni az oldalanként történő mozgást, meg kell változtatnunk ezt az osztályt. Számos oka lehet a változásnak.

osztálykönyv {

    függvény getTitle () {

        vissza az „Oceano Mare”;

    }

    függvény getAuthor () {

        visszatér Alessandro Baricco;

    }

    function turn page () {

        // következő oldal

    }

    függvény getCurrentPage () {

        return "az aktuális oldal tartalma";

    }

}

class SimpleFilePersistence {

    függvény mentése (Book $ book) {

        $ fájlnév = '/ dokumentumok /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();

        file_put_contents ($ fájlnév, sorozatosítás ($ könyv));

    }

}

A kitartási művelet áthelyezése egy másik osztályba egyértelműen elkülöníti a felelősségeket, és szabadon cserélhetjük a perzisztencia módszereket anélkül, hogy befolyásolnánk a könyv osztályunkat. Például egy DatabasePersistence osztály megvalósítása triviális lenne, és a könyvműveletek köré épített üzleti logikánk nem fog változni.

Folytassa a második elv nyitott / zárt -> elolvasásával

1 megjegyzés

Szólj hozzá

Il tuo Indirizzo email nem Sara Pubblicato. Azt campi sono obbligatori contrassegnati *

liskov elv
edzés
A Liskov-helyettesítés elve, harmadik SOLID-elv

A gyermekosztályoknak soha nem szabad befolyásolniuk vagy megváltoztatniuk a szülőosztály típusmeghatározásait. Ennek az elvnek a koncepcióját Barbara Liskov vezette be az 1987-es konferencia egyik fő beszámolójában, majd ezt követően 1994-ben Jannette Winggel együtt egy cikkben publikálta. Eredeti meghatározásuk…

google marketing trendek
edzés
A Google Trends használata valós idejű marketinghez

Az egyik legnagyobb nehézség, amellyel a vállalatok 2020-ban szembesültek, az volt, hogy megértsék, melyik termékágazatban diverzifikálják üzleti tevékenységüket: az ipari szektorok többsége súlyos következményeket szenvedett el, ami szinte lehetetlenné teszi a vállalatok számára azok behatolását, különösen új szereplőként. Nagyon kevés gyártási ágazat ...

üzleti intelligencia stratégia
mód
Stratégiák a sikeres üzleti intelligencia érdekében

Az üzleti intelligencia sikeres stratégiájának kiépítése a célok helyes elképzelésével kezdődik. Az alábbiakban néhány alapvető pontot látunk. A jelenlegi helyzet értékelése Súlyos hiba lenne ezt a szempontot alábecsülni. A jelenlegi helyzet értékelése folyamatok, struktúrák elemzését jelenti ...