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.
