Objektumorientált tervezési alapelvek Flashcards
Mi a statikus kódelemzés és adj példát statikus kódelemző eszközökre?
A programkód elemzésének folyamata, mely a kód végrehajtása nélkül történik.
Hibák észlelésére, szabványnak megfelel e kód
Statikus kódelemző eszközök:
C# - InterSharp
C++ - Cppcheck
ECMAScript/JavaScript - ESLint, JSHint, JSLint, RSLint
Java - Checkstyle, Error Prone, PMD
Mi a DRY és milyen fajtái vannak?
Don’t repeat yourself - mindennek egyetlen, egyértelmű hiteles reprezentációja kell, hogy legyen
Ellenkezője a WET - „We enjoy typing”, „write everything twice”, „waste
everyone’s time”.
Fajtái:
- Kényszerített ismétlés - fejlesztők úgy érzik, hogy nincs választásuk, a környezet megkényszeríti az ismétlést
- Nem szándékos ismétlés - fejlesztők nem veszik észre
- Türelmetlen ismétlés - lustaságból fakadó ismétlés
- Fejlesztők közötti ismétlés - csapatban többen duplikálnak
Nem mindig kódismétlésben jelenik meg, az információ megismétléséről szól.
Jellemezd a KISS elvet!
Keep it simple, stupid - egyszerűségre való törekvés
„Mindent olyan egyszerűen kell csinálni, amennyire csak lehetséges, de semmivel sem egyszerűbben.”
Jellemezd a YAGNI elvet!
You aren’t gonna need it - nem lesz rá szükség
Mindig akkor implementálj valamit, amikor tényleg szükség van rá.
Arra vonatkozik, hogy egy feltételezett lehetőség támogatásához kerülnek beépítésre a szoftverbe, nem vonatkozik a szoftver módosítását könnyítő törekvésre.
Csak akkor járható, ha a kód könnyen változtatható.
Jellemezd a csatoltságot!
Szoftvermodul függésének mérete másik szoftvermodultól.
Lehet:
szoros - bonyolultságot növeli, nehezíti a módosítást és a karbantarthatóságot és újrafelhasználhatóságot
laza - kiterjeszthetővé teszi a kódot, az pedig karbantarthatóvá,
lehetővé teszi a párhuzamos fejlesztést
Jellemezd a Demeter törvényét!
Ne beszélgess idegenekkel. Metódusok üzenetküldési lehetőségét korlátozza. Az osztályok közötti függőségek szervezése és csökkentése.
Elősegíti az érthetőséget és karbantarthatóságot. Szűkíti a metódusok meghívható körét, korlátozza a csatoltságát. Az objektum belső felépitését kizárólag maga ismeri.
Osztályokra vonatkozó változat:
C osztály M metódusát csak C, C adattagjainak osztályai, osztályok melynek konstruktorai M-ben meghívásra kerülnek, M-ben használt globális változók osztályai
Fordítási időben ellenőrizhető
Objektumokra vonatkozó változat:
O objektum M metódusát csak O, O adattagjai, M-ben létrehozott, példányosított objektumok, globális változókban lévő objektumok
Futási időben ellenőrizhető
Jellemezd a GoF alapelveket!
Interfészre programozzunk, ne implementációra.
Részesítsük előnyben az objektum-összetételt az öröklődéssel szemben.
Újrafelhasználás módszerei:
- öröklődés (fehér dobozos újrafelhasználás)
- objektum-összetétel (fekete dobozos újrafelhasználás)
láthatóságra utal
Jellemezd az öröklődést!
előnyei: statikusan, fordítási időben történik, könnyebbé teszi az újrafelhasznált megvalósítás módosítását
hátrányai: szülőosztályban örökölt megvalósításokat futási időben nem változtathatjuk, szülőosztályok az alosztályok fizikai ábrázolását is meghatározzák, implementációs gondot okozhat az alosztály újrafelhasználása
Jellemezd az objektum-összetételt!
Dinamikusan futási időben történik, olyan objektumokkal melyek hivatkozásokat szereznek más objektumokra. Szükséges, hogy észrevegyék egymás gondosan megtervezett interfészét.
előnyei: csak interfészeken keresztül lehet elérni, így az egységbe zárást nem sértjük meg, amíg a típus egyezik bármely objektumot cserélhetünk másra futási időben, segít az egységbe zárásban, osztályok és osztályhierarchiák kicsik maradnak
hátrányai: több objektumunk lesz, a rendszer viselkedése ezen kapcsolatoktól függ, nem egyetlen osztálytól
Sorold fel a SOLID alapelveket!
- Single Responsibility Principle (SRP) – Egyszeres
felelősség elve - Open/Closed Principle (OCP) – Nyitva zárt elv
- Liskov Substitution Principle (LSP) – Liskov-féle
helyettesítési elv - Interface Segregation Principle (ISP) – Interfész
szétválasztási elv - Dependency Inversion Principle (DIP) – Függőség
megfordítási elv
Jellemezd a SOLID egyszeres felelősség elvét!
Egy osztálynak csak egy oka legyen a változásra.
Egy felelősség egy ok a változásra.
Ha több felelősség van akkor több oka van a változásra, a felelősségek csatolttá válnak.
Szoftverek aktorok kielégítése céljából változnak. Egy modul egy és csak egyetlen aktornak van alárendelve.
Jellemezd a nyitva zárt elvet!
A szoftver entitások nyitottak kell legyenek a bővítésre, de zártak a módosításra. Nyitott a bővítésre, azaz a modul kiterjeszthető.
Zárt a módosításra, azaz a kiterjesztés nem eredményezi a modul forráskódjának a változását.
Jellemezd a Liskov-féle helyettesítési elvet!
Az S típus a T altípusa, nem változhat egy program működése, ha egy T típusú objektumot S-el helyettesítjük.
Jellemezd az interfész szétválasztási elvet!
Nem szabad arra kényszeríteni az osztályokat, hogy olyan metódusoktól függjenek, melyek nem használnak.
Vastag interfész - szükségesnél több tagfüggvénnyel és baráttal rendelkező interfész.
Vastag interfészekkel rendelkező osztályok nem koherensek, a metódusokat olyan csoportokra lehet felosztani, melyek különböző klienseket szolgálnak ki.
Interfész szennyezés - egy interfész szennyezése szükségtelen metódusokkal.
Ha egy kliens olyan osztálytól függ, melynek egyes metódusait nem használja de más kliens igen, akkor a kliensek között nem szándékos csatoltság jön létre.
Jellemezd a függőség megfordítási elvet!
Magas szintű modulok ne függjenek az alacsony szintűektől. Mindkettő absztrakcióktól függjön. Az absztrakciók ne függjenek a részletektől, a részletek függjenek az absztrakcióktól.
Magas szintű modulok újrafelhasználását eredményezi.
Jellemezd a függőség befecskendezést!
Olyan szoftvertervezési minták összessége, melyek lazán csatolt kód fejlesztését teszik lehetővé. Ami kiterjeszthetővé, majd pedig karbantarthatóvá.
Egy objektum egy olyan szolgáltatás, mely más objektumoknak kliens lesz. Ez lesz kliens-szolgáltató kapcsolat, ami függés.
Sorold fel a függőség befecskendezés elemeit!
Függőség - kliens által igényelt szolgáltatás
Függő - kliens objektum, melynek szüksége van egy függőségre
Objektum gráf - függő objektumok és függőségeik egy összessége
Befecskendezés - kliens függőségeinek megadása
DI konténer - függőség befecskendezési funkcionalitást nyújtó programkönyvtárak
Tiszta DI - függőség befecskendezés alkalmazása DI nélkül
