oktatói

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

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 használata defielmagyarázza 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;

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

Innovációs hírlevél
Ne maradjon le az innovációval kapcsolatos legfontosabb hírekről. Regisztráljon, hogy megkapja őket e-mailben.

}

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

    }

}

osztály 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

Ercole Palmeri

Innovációs hírlevél
Ne maradjon le az innovációval kapcsolatos legfontosabb hírekről. Regisztráljon, hogy megkapja őket e-mailben.

Friss cikkek

Smart Lock Market: piackutatási jelentés közzététele

A Smart Lock Market kifejezés a termelést, forgalmazást és felhasználást körülvevő iparágra és ökoszisztémára utal…

Március 27 2024

Mik azok a tervezési minták: miért használja őket, osztályozás, előnyei és hátrányai

A szoftverfejlesztésben a tervezési minták optimális megoldást jelentenek a szoftvertervezés során gyakran előforduló problémákra. Olyan vagyok, mint…

Március 26 2024

Az ipari jelölés technológiai fejlődése

Az ipari jelölés egy tág fogalom, amely számos olyan technikát ölel fel, amellyel tartós nyomokat lehet létrehozni egy…

Március 25 2024

Példák VBA-val írt Excel makrókra

A következő egyszerű Excel makrópéldákat VBA segítségével írtuk. Becsült olvasási idő: 3 perc Példa…

Március 25 2024