8.1 A bomlás minden
Az érthetőség kedvéért egy kép egy jó cikkből: "Objektum-orientált rendszerek szétkapcsolása", illusztrálva a megvitatásra kerülő főbb pontokat.
Még mindig úgy gondolja, hogy egyszerű az alkalmazásarchitektúra tervezése?
8.2 Interfészek, megvalósítás elrejtése
A rendszer csatolásának csökkentésének főbb elvei az OOP elvei és a mögöttük lévő Encapsulation + Absztrakció + Polimorfizmus elve.
Ezért:
- A modulok „fekete dobozok” legyenek egymás számára (kapszulázás) . Ez azt jelenti, hogy az egyik modulnak nem szabad „bemásznia” egy másik modulba, és semmit sem kell tudnia annak belső felépítéséről. Az egyik alrendszerben lévő objektumok nem férhetnek hozzá közvetlenül egy másik alrendszer objektumaihoz.
- A moduloknak/alrendszereknek csak interfészeken (vagyis olyan absztrakciókon ) keresztül kell kölcsönhatásba lépniük egymással , amelyek nem függnek a megvalósítás részleteitől. Ennek megfelelően minden modulnak jól meghatározott interfésszel vagy interfészekkel kell rendelkeznie a többi modullal való interakcióhoz.
A "fekete doboz" (beágyazás) elve lehetővé teszi, hogy az egyes alrendszerek felépítését a többi alrendszertől függetlenül vizsgáljuk meg. A modul, ami egy „fekete doboz”, viszonylag szabadon cserélhető. Problémák csak a különböző modulok (vagy egy modul és egy környezet) találkozásánál merülhetnek fel.
Ezt az interakciót pedig a legáltalánosabb (absztrakt) formában kell leírni, vagyis interfész formájában. Ebben az esetben a kód ugyanúgy fog működni minden olyan implementációval, amely megfelel az interfészszerződésnek. Ez a képesség, hogy különböző implementációkkal (modulokkal vagy objektumokkal) dolgozzon egy egységes felületen keresztül, amit polimorfizmusnak nevezünk.
Ezért a Servlet egy interfész : a webkonténer nem tud semmit a servletekről, számára ezek néhány objektum, amelyek megvalósítják a Servlet felületet, és ennyi. A szervletek egy keveset tudnak a tároló szerkezetéről is. A Servlet felület az a szerződés, az a szabvány, az a minimális interakció, amely ahhoz szükséges, hogy a Java webalkalmazások átvegyék a világot.
A polimorfizmus egyáltalán nem a módszerek felülbírálása, ahogyan néha tévesen hiszik, hanem mindenekelőtt az azonos interfésszel rendelkező modulok / objektumok felcserélhetősége vagy „egy interfész, sok megvalósítás”. A polimorfizmus megvalósításához egyáltalán nincs szükség az öröklődési mechanizmusra. Ezt fontos megérteni, mert az öröklődést általában lehetőleg kerülni kell .
Az interfészeknek és a polimorfizmusnak köszönhetően éppen az a lehetőség érhető el, hogy a kódot módosítani és bővíteni lehessen anélkül, hogy a már leírtakat megváltoztatnánk (Open-Closed Principle).
Mindaddig, amíg a modulok interakciója kizárólag interfészek formájában van leírva, és nem kötődik konkrét megvalósításokhoz, lehetősége van arra, hogy a rendszer számára teljesen „fájdalommentesen” cserélje ki az egyik modult egy másik, ugyanazt az interfészt megvalósító modulra, valamint adjon hozzá egy újat, és ezzel bővítse a funkciókat.
Olyan ez, mint a LEGO konstruktorban – az interfész szabványosítja az interakciót, és egyfajta csatlakozóként szolgál, ahová bármilyen megfelelő csatlakozóval rendelkező modul csatlakoztatható.
A tervező rugalmasságát biztosítja, hogy egyszerűen kicserélhetjük az egyik modult vagy alkatrészt egy másikra, ugyanazokkal a csatlakozókkal (azonos interfésszel), valamint tetszőleges számú új alkatrészt tudunk hozzáadni (egyidejűleg meglévő az alkatrészeket semmilyen módon nem módosítják vagy módosítják).
Az interfészek lehetővé teszik egy egyszerűbb rendszer felépítését, az egyes alrendszerek egészének figyelembevételével, és figyelmen kívül hagyva a belső szerkezetüket. Lehetővé teszik a modulok interakcióját, ugyanakkor semmit sem tudnak egymás belső felépítéséről, ezáltal teljes mértékben megvalósítják a minimális tudás elvét, amely a laza csatolás alapja.
Minél általánosabb/absztraktabbak az interfészek, és minél kevesebb korlátozást szabnak az interakcióra, annál rugalmasabb a rendszer. Innen a SOLID egy további alapelve következik – az Interface Segregation Principle , amely szembehelyezkedik a „vastag interfészekkel”.
Szerinte a nagy, terjedelmes interfészeket kisebb, specifikusabb interfészekre kellene bontani, hogy a kis felületek (moduloktól függően) kliensei csak azokról a metódusokról tudjanak, amelyekkel dolgozniuk kell.
Ez az elv a következőképpen fogalmazódik meg: „Az ügyfelek ne függjenek olyan módszerektől (legyen tisztában a módszerekkel), amelyeket nem használnak” vagy „Sok speciális interfész jobb, mint egy univerzális”.
Kiderül, hogy gyenge összekapcsolhatóság csak akkor érhető el, ha a modulok interakcióját és függőségeit csak interfészek, azaz absztrakciók segítségével írjuk le, anélkül, hogy a belső szerkezetükről és felépítésükről ismernénk, és valójában így valósul meg a beágyazás. Ráadásul lehetőségünk van a rendszer viselkedésének bővítésére/módosítására különböző implementációk hozzáadásával és használatával, vagyis a polimorfizmus miatt. Igen, ismét elérkeztünk az OOP-hoz - Encapsulation, Abstraction, Polymorphism.
8.3 Homlokzat: modul interfész
Itt egy tapasztalt programozó megkérdezi: ha a tervezés nem az objektumok szintjén történik, amelyek maguk valósítják meg a megfelelő interfészt, hanem a modulok szintjén, akkor mi a modul interfész megvalósítása?
Válasz: a tervezési minták nyelvén szólva egy speciális objektum lehet felelős a modulfelület megvalósításáért - Homlokzat . Ha metódusokat hív meg egy olyan objektumon, amely tartalmazza az átjáró utótagot (például MobileApiGateway), akkor valószínűleg egy homlokzatról van szó.
A homlokzat egy interfészobjektum , amely magas szintű műveleteket halmoz fel egy bizonyos alrendszerrel való munkavégzéshez, elrejtve mögötte annak belső szerkezetét és valódi összetettségét . Védelmet nyújt az alrendszer megvalósításában bekövetkezett változások ellen. Egyetlen belépési pontként szolgál - "Ön felrúgja a homlokzatot, és ő tudja, kit kell rúgni ebben az alrendszerben, hogy megkapja, amire szüksége van."
Most ismerkedhetett meg az egyik legfontosabb tervezési mintával, amely lehetővé teszi az interfészek fogalmának használatát a modulok tervezése során, és ezáltal szétválaszthatja azokat - a "Homlokzat".
Ezenkívül a "homlokzat" lehetővé teszi, hogy a modulokkal ugyanúgy dolgozzon, mint a közönséges tárgyakkal, és alkalmazza az összes hasznos elvet és technikát, amelyet az osztályok tervezése során használnak a modulok tervezése során.
Megjegyzés : Bár a legtöbb programozó megérti az interfészek fontosságát az osztályok (objektumok) tervezésekor, úgy tűnik, hogy sokan felfedezik az interfészek modulszintű használatának ötletét.