Elég gyakran találkozom olyan fejlesztőkkel, akik nem hallottak a SOLID elvekről (mi . — Transl.) vagy objektum-orientált programozás (OOP), vagy hallott már róluk, de a gyakorlatban nem használja. Ez a cikk az OOP-elvek előnyeit írja le, amelyek segítik a fejlesztőt a napi munkájában. Néhányuk jól ismert, mások nem annyira, így a cikk hasznos lesz kezdőknek és tapasztalt programozóknak egyaránt.
Emlékeztetünk: minden Habr olvasó számára - 10 000 rubel kedvezmény, ha a Habr promóciós kóddal bármely Skillbox tanfolyamra jelentkezik.
A Skillbox a következőket ajánlja: Oktató online tanfolyam .
SZÁRAZ (Ne ismételd magad)
Meglehetősen egyszerű alapelv, melynek lényege a névből is kiderül: „Ne ismételd magad.” A programozó számára ez azt jelenti, hogy kerülni kell a duplikált kódot, valamint lehetőséget kell adni az absztrakció használatára a munkájában.
Ha két ismétlődő szakasz van a kódban, akkor azokat egy metódusba kell kombinálni. Ha egy kódolt értéket többször használunk, akkor érdemes nyilvános konstanssá konvertálni.
Erre azért van szükség, hogy leegyszerűsítsük a kódot és könnyebben karbantartható legyen, ami az OOP fő célja. Nem szabad túlzásba vinni az uniót sem, mivel ugyanaz a kód nem megy át az OrderId és az SSN ellenőrzésén.
Változások beágyazása
A legtöbb vállalat szoftvertermékei folyamatosan fejlődnek. Ez azt jelenti, hogy módosítani kell a kódon, támogatni kell. Könnyebbé teheti életét a kapszulázással. Ez lehetővé teszi a meglévő kódbázis hatékonyabb tesztelését és karbantartását. .
Ha Java-ban írsz, akkor .
Nyitott/zárt elv
Ez az elv könnyen megjegyezhető, ha elolvassa a következő kijelentést: „A szoftver entitások (osztályok, modulok, függvények stb.) legyenek nyitva a bővítésre, de zárva legyenek a módosításra.” A gyakorlatban ez azt jelenti, hogy megengedhetik viselkedésük megváltoztatását a forráskód megváltoztatása nélkül.
Az elv akkor fontos, ha a forráskód módosításai kódfelülvizsgálatot, egységtesztet és egyéb eljárásokat igényelnek. A nyitott/zárt elvet követő kód kiterjesztéskor nem változik, így sokkal kevesebb probléma van vele.
Íme egy példa arra a kódra, amely sérti ezt az elvet.
Ha valamit módosítania kell benne, az sok időt vesz igénybe, mivel a kód minden olyan szakaszát meg kell változtatni, amely kapcsolatban áll a kívánt töredékkel.
A nyitottság-zártság egyébként a SOLID egyik alapelve.
Egységes Felelősség Elve (SRP)
Egy másik alapelv a SOLID készletből. Kijelenti, hogy „csak egy ok van, amely változást okoz az osztályban”. Az osztály csak egy problémát old meg. Több módszer is lehet, de mindegyiket csak egy közös probléma megoldására használják. Minden módszer és tulajdonság csak ezt szolgálja.
Ennek az elvnek az az értéke, hogy fellazítja az egyes szoftverkomponensek és a kód közötti kapcsolatot. Ha egynél több funkciót ad hozzá egy osztályhoz, az kapcsolatot hoz létre a két függvény között. Így ha az egyiket megváltoztatja, nagy eséllyel tönkreteszi a másodikat, amely az elsőhöz kapcsolódik. Ez pedig a tesztelési ciklusok növelését jelenti az összes probléma előzetes azonosítása érdekében.
Függőség-inverziós elv (DIP)
A fenti példa egy olyan kódra, ahol az AppManager az EventLogWritertől függ, amely viszont szorosan kapcsolódik az AppManagerhez. Ha más módra van szüksége az értesítések megjelenítésére, legyen az push, SMS vagy e-mail, módosítania kell az AppManager osztályt.
A probléma DIP segítségével megoldható. Tehát az AppManager helyett egy EventLogWriter-t kérünk, amely a keretrendszer segítségével kerül bevitelre.
A DIP lehetővé teszi az egyes modulok egyszerű cseréjét másokkal a függőségi modul megváltoztatásával. Ez lehetővé teszi egy modul megváltoztatását anélkül, hogy ez a többire hatással lenne.
Öröklés helyett összetétel
A kód újrafelhasználásának két fő módja van: az öröklődés és az összetétel, mindkettőnek megvannak a maga előnyei és hátrányai. Általában a másodikat részesítik előnyben, mert rugalmasabb.
A kompozíció lehetővé teszi egy osztály viselkedésének megváltoztatását futás közben a tulajdonságainak beállításával. Az interfészek implementálásakor polimorfizmust alkalmazunk, ami rugalmasabb megvalósítást ad.
Még a Joshua Bloch által készített Effective Java is azt tanácsolja, hogy a kompozíciót válasszuk az öröklődés helyett.
Barbara Liskov helyettesítési elv (LSP)
Egy másik alapelv a SOLID eszköztárból. Kimondja, hogy az altípusoknak helyettesíthetőnek kell lenniük a szupertípussal. Vagyis azoknak a metódusoknak és függvényeknek, amelyek egy szuperosztállyal működnek, problémamentesen kell működniük annak alosztályaival.
Az LSP mind az egységes felelősség elvéhez, mind a megosztott felelősség elvéhez kapcsolódik. Ha egy osztály több funkcionalitást biztosít, mint egy alosztály, akkor az utóbbi nem támogatja a funkciók egy részét, megsértve ezt az elvet.
Itt van egy kódrészlet, amely ellentmond az LSP-nek.
A terület (Rectangle r) módszer kiszámítja a téglalap területét. A program összeomlik a Négyzet végrehajtása után, mert a négyzet itt nem téglalap. Az LSP elv szerint az alaposztályokra hivatkozásokat használó függvényeknek képesnek kell lenniük a származtatott osztályok objektumaira további utasítások nélkül.
Ezt az elvet, amely egy altípus sajátos meghatározása, Barbara Liskov javasolta egy 1987-es konferencia „Adatabsztrakció és hierarchia” című vitaindítójában, innen ered a neve.
Interface Separation Principle (ISP)
Egy másik SZILÁRD elv. Eszerint nem használt felületet nem szabad megvalósítani. Ennek az elvnek a követése segít abban, hogy a rendszer rugalmas maradjon, és alkalmas legyen a működési logika változtatásakor történő átdolgozásra.
Leggyakrabban ez a helyzet akkor fordul elő, ha az interfész egyszerre több funkciót tartalmaz, és az ügyfélnek csak az egyikre van szüksége.
Mivel a felület megírása nehéz feladat, a munka befejezése után megváltoztatni, anélkül, hogy bármit is eltörne, kihívás lesz.
Az ISP-elv előnye a Java-ban, hogy először minden metódust implementálni kell, és csak ezután használhatják az osztályok. Ezért az elv lehetővé teszi a módszerek számának csökkentését.
Programozás az interfészhez, nem a megvalósításhoz
A címből itt minden kiderül. Ennek az elvnek az alkalmazása olyan rugalmas kód létrehozásához vezet, amely az interfész bármely új megvalósításával működik.
Használja az interfész típust a változókhoz, a visszatérési típusokhoz vagy a metódus argumentumtípusához. Példa erre a SuperClass használata az alosztály helyett.
Azaz:
Lista számok= getNumbers();
De nem:
ArrayList numbers = getNumbers();
Íme a fentebb tárgyaltak gyakorlati megvalósítása.
A delegálás elve
Gyakori példa erre az equals() és a hashCode() metódusok Java-ban. Ha két objektumot kell összehasonlítani, akkor ezt a műveletet a rendszer a megfelelő osztályra delegálja az ügyfél osztálya helyett.
Az elv előnye, hogy nincs kódduplikáció, és viszonylag egyszerű a viselkedés megváltoztatása. Ez vonatkozik a rendezvények delegálására is.
Mindezek az elvek lehetővé teszik, hogy rugalmasabb, szebb és megbízhatóbb kódot írjon, magas kohézióval és alacsony csatolással. Természetesen az elmélet jó, de ahhoz, hogy egy fejlesztő a megszerzett tudást valóban használni tudja, gyakorlatra van szükség. Miután elsajátította az OOP alapelveit, a következő lépés a tervezési minták elsajátítása lehet a gyakori szoftverfejlesztési problémák megoldásához.
A Skillbox a következőket ajánlja:
- Gyakorlati tanfolyam .
- Jelentkezett online tanfolyam .
- Két éves gyakorlati tanfolyam .
Forrás: will.com