Három objektum-orientált tervezési elv, amelyet mindenképpen használnia kell!

Keylearnings:

Mi a hollywoodi elv?
Mit jelent a függőségi inverzió?
Mit jelent a legkevesebb tudás elve?
Mi a Demeters törvény?

Már beszéltünk arról, hogy bizonyos szabályok betartása miért menthet meg minket a kék szemek halmazától.

Egyrészt nem egyedül dolgozunk, főleg nagyobb projekteken, és kollégáinknak is képesnek kell lenniük arra, hogy idegösszeomlás nélkül dolgozzanak a kódunkkal, és képesnek kell lenniük újrafelhasználásra.

De természetesen mi magunk is profitálunk belőle.

A nagymama almás pite a legjobb!

Miért kell tehát megváltoztatni a receptet, amikor egy problémát bevált és mindenekelőtt ismert módon megoldhatunk.

Ezért ebben a cikkben még három objektum-orientált tervezési elvvel kívánunk foglalkozni.

A hollywoodi elv

Ne hívjon minket, hanem hívunk!

Vagy németül: felvesszük Önnel a kapcsolatot!

Hollywoodban az ügynökök úgy látják, hogy leadják a jelölteket.

Amint a jelölt alkalmasnak bizonyul, erről az ügynök tájékoztatja. Ezzel szemben az ügynököt nem tudja elérni a jelölt.

Az események egy objektum-orientált koncepció, amely pontosan ennek az elvnek megfelelően működik.

Például hogyan működnek az események egy szövegszerkesztőn belül?

A szövegszerkesztő, például a Word, két területből áll.

Egyrészt az a terület, ahol a szöveges dokumentumot szerkeszti, másrészt egy menü, amelyben megadhatja például a betűtípust, a betűméretet vagy a szöveg színét.

Ki az ügynök itt és ki a jelölt?

Jelölt és ügynök helyett előfizetőről és megfigyelőről beszélünk a programozásban.

Természetesen nem lenne különösebben hatékony, ha a dokumentumterület folyamatosan megkérdezi a formázási menüt, hogy a felhasználó módosította-e a szövegformázást.

Ezért, amint a felhasználó a menüben átformázta a szöveget, elindul egy esemény, amelyről a dokumentumterület tájékoztatást kap, majd ennek megfelelően reagál.

Ezért ebben a példában a formázási menü megfigyelő (ügynök) szerepet tölt be, és a dokumentumterület az az előfizető, aki a menüből várja az értesítéseket.

A hollywoodi elv különös jelentőséggel bír az úgynevezett keretek kapcsán.

A keretrendszerek olyan programkönyvtárak, amelyek mentesítik a fejlesztőt bizonyos szabványos feladatoktól.

Például vannak olyan keretrendszerek, mint a Java FX, amely átveszi az interakciót a felhasználóval egy számunkra grafikus felhasználói felületen.

Például, ha a felhasználó egy gombra kattint, a keretrendszeren keresztül értesülünk erről a műveletről, és ennek megfelelően reagálhatunk.

A függőségi inverzió elve

A következő elv, amelyet figyelembe akarunk venni, a függőségi inverzió elve.

Ez az elv az absztrakciót és a független megvalósítást helyezi előtérbe.

Nem az áramról van szó, hanem csak a dugóról és aljzatról.

Ennek az elvnek a megvalósításához az úgynevezett proxy mintát alkalmazzuk, amely lehetővé teszi a módszer alkalmazását annak konkrét megvalósításától függetlenül.

Az ehhez használt eszköz a Java interfészek.

CRUD adatbázis-műveletek

A függőségi inverzió elvének híres példája az adatbázishoz való csatlakozás a JPA-n keresztül (Java Persistence Architecture).

A JPA interfészként szolgál az alkalmazott adatbázis-rendszerhez.

Minden adatbázisban szükségünk van úgynevezett CRUD műveletekre: Létrehozás, Olvasás, Frissítés és Törlés, amelyekkel adatbázis bejegyzéseket hozhatunk létre, olvashatunk, módosíthatunk és törölhetünk.

Ezeknek a műveleteknek a végrehajtása azonban különbözik a különféle adatbázis-rendszerek között.

Például ezeknek a műveleteknek az végrehajtása egy Oracle adatbázisban más, mint egy MySql adatbázisban.

JPA nélkül minden adatbázis-rendszerhez külön CRUD megvalósítást kell írnunk.

Például egy külön mentési módszerrel rendelkeznénk, például saveSQL, savePostgresSQL vagy saveOracle minden adatbázis-rendszerhez .

A mentési műveletet használni kívánó fejlesztőnek minden alkalommal ellenőriznie kell, hogy melyik adatbázis-rendszert használják, és ettől függően a megfelelő CRUD-módszert kell meghívnia.

Ha valakinek ötlete támadna az adatbázis-rendszer megváltoztatására, megfelelő kódbeállításokra van szükség.

A JPA felületének köszönhetően ezt megkíméljük. A használt adatbázis-rendszertől függően dinamikusan dokkolhatjuk a megfelelő megvalósítást a JPA proxyhoz (még a program futása közben is).

A CRUD műveletet használni kívánó fejlesztő az alapul szolgáló megvalósítástól függetlenül meghívhatja az interfész CRUD metódusait, például a mentést.

Maguk a különböző megvalósítások függetlenek egymástól.

A legkevesebb ismeret elve!

Sokszor beszéltünk róla. A programozók lusták, és mindig keresik a munka megtakarításának módját.

Ennek jó módja a más fejlesztők által végzett munka felhasználása.

Ez azonban csak akkor hasznos, ha a külföldi programkóddal való ismerkedési idő a lehető legrövidebb.

És itt lép életbe az úgynevezett legkevesebb tudás elve, vagy németül a kevés tudás elve.

Ez az elv különösen fontos az API (Application Programming Interface) tervezéssel kapcsolatban.

Te is biztosan tudod ezt? Ha kérdése van. Kihez fordulsz Jó barát vagy idegen a gyalogos zónából?

Valószínűleg inkább kapcsolatba lép az ismerősével. Vagy?

És pontosan ez az az alap, amelyen a legkevesebb tudás elve alapul, amelyet Demeter törvénye néven is ismerünk.

Demeter törvénye azt javasolja, hogy először kérdezzünk meg egy barátot, és csak ezután vegyük fel a kapcsolatot egy idegenrel, ha haverunk nem tud segíteni rajtunk.

Ki barát és ki idegen?

Bizonyára még soha nem ittál módszert, osztályt vagy attribútumot tartalmazó sört. Vagy? Tehát hogyan határozhatjuk meg programjainkban, hogy ki a barát, és ki az, aki idegen?.

Mivel a Demiter-törvény objektum-orientált tervezési elv, meg kell határoznunk, hogy az objektum mely módszerei és tulajdonságai tartoznak a barátainkhoz.

Logikus, hogy ugyanazon osztályon belül minden módszer barátságos. A módszerek ugyanazon osztályon belüli kölcsönös behívása tehát a Demiter törvényben megengedett.

Ki más az egyik barátunk?

Hasonlóképpen, minden olyan objektumra utalunk, amelyet paraméterként adunk át a módszer meghívásakor, mint barátaink.

Továbbá, minden tárgy (és attribútumuk), amelyet ugyanazon osztályon belül hozunk létre, szintén a baráti körünkbe tartozik.

Az a jelző, hogy megsérted a Demiter törvényét, ha a módszerhívásodnak több (.) Operátora van.

Oké, gyakoroljuk a tanultakat egy példával.

Egy könyvtárban vagyunk.

A könyvtár könyvespolcokból áll.

Ahhoz, hogy ezt az objektumorientált Java-ban feltérképezzük, két osztályra van szükségünk. Egy osztály a polcokra és egy osztály maga a könyvtár.

A könyvespolcok nyilván a könyvtárhoz tartoznak. Ezért a polcok barátok a könyvtárral.

Minden könyvespolc tartalmazza azoknak a könyveknek a számát, amelyeket attribútumként tartalmaz.

Tehát a könyvek száma attribútum a Könyvespolc osztály barátja, a Könyvtár osztályé azonban nem .

Mert tegyük fel, hogy meg akarjuk tudni a könyvtár tizedik polcán található könyvek számát. Hogyan nézhet ki egy megfelelő metódushívás?

A fellebbezésünk két pontot tartalmaz. Nyilvánvaló, hogy itt megsértjük a Demeters törvényt. Valójában a „könyvek száma” attribútum nem ismeri a könyvtári osztályt.

Hogyan tudjuk a hívást a Demeters törvénynek megfelelni?

A probléma kiküszöböléséhez hozzá kell adnunk egy módszert a könyvtár osztályhoz, amely közvetlenül visszaadja a polcon lévő könyvek számát.

Egy ilyen módszer például így nézhet ki.

Mivel a polcok a könyvtárban vannak, a polc attribútum a könyvtár osztály barátja. A demeters törvényt tehát a getAnzahlRegal módszer nem sérti.

Most megkapjuk a 10. polcon lévő könyvek számát a következő módszerrel.

Mivel a getAnzahlInRegal módszer a könyvtár osztály barátja, ebben az esetben nem sértettük meg a Demeters törvényt.

Következtetés: Ebben a cikkben további három objektum-orientált tervezési elvet ismertett meg. A hollywoodi elv az úgynevezett keretrendszerek alapja, amelyek mentesítenek a gyakorlatban sok ismétlődő és gyakran unalmas rutinfeladattól.

A függőségi inverzió lehetővé teszi számunkra, hogy az API-val (Application Programming Interfaces) dolgozzunk, elválasztva a függvény definícióját és megvalósítását.

Minden tervezési elv alapvető szempontja, de különösen a legkevesebb ismeret elve mellett könnyebbé teszi a kód újrafelhasználhatóvá, érthetőbbé és karbantartásbarátabbá tételét.

Tetszett a cikk? Akkor azonnal kövessen minket a Facebookon!

Kim Peter

Szia, a nevem Kim, és nagyszerű programozóvá akarok válni. Részt veszel?