3.1 Singleton
A Singleton egy általános tervezési minta, amely garantálja, hogy egy egyszálú alkalmazásnak egyetlen osztálya legyen, és globális hozzáférési pontot biztosít ehhez a példányhoz.
Nagyon gyakran a kezdő programozók szeretik a segédprogramokat valamilyen statikus osztályba összeállítani – egy olyan osztályba, amely csak statikus metódusokat tartalmaz. Ennek a megközelítésnek számos hátránya van - például nem adhat át hivatkozást egy ilyen osztály objektumára, az ilyen módszereket nehéz tesztelni és hasonlók.
Alternatív megoldásként egy szimpla osztályú megoldást javasoltak: egy olyan osztályt, amelynek csak egy objektuma lehet. Amikor megpróbálja létrehozni ezt az objektumot, akkor csak akkor jön létre, ha még nem létezik, ellenkező esetben a rendszer egy már létező példányra való hivatkozást ad vissza.
Lényeges, hogy az osztály egy példányát lehessen használni, mivel sok esetben szélesebb körű funkcionalitás válik elérhetővé. Például ez az osztály megvalósíthat néhány interfészt, és objektuma átadható más metódusoknak az interfész megvalósításaként. Mit nem lehet megtenni egy sor statikus módszerrel.
Előnyök:
- A metódusok egy objektumhoz vannak kötve, nem egy statikus osztályhoz – egy objektumot hivatkozással is átadhat.
- Az objektummódszerek sokkal könnyebben tesztelhetők és gúnyolhatók.
- Egy objektum csak szükség esetén jön létre: lusta objektum inicializálás.
- A program kezdeti indításának felgyorsítása, ha sok olyan kislemez van, amelyre nincs szükség az indításhoz.
- Egyedül tovább alakítható sablon-stratégiává vagy több ilyen objektummá.
Mínuszok:
- Nehezebbé válik a szálak közötti versenyek és késések ellenőrzése.
- Nehéz többszálú „magányost” írni „fejből”: a régóta fennálló szinglihez való hozzáférés ideális esetben nem nyithat mutexet. Jobban bevált megoldások.
- Két szál közötti ütközés egy befejezetlen egyetlen szál miatt késést eredményez.
- Ha az objektumot hosszú ideig hozzuk létre, a késleltetés zavarhatja a felhasználót, vagy megzavarhatja a valós időt. Ebben az esetben jobb a létrehozását átvinni a program inicializálásának szakaszába.
- Az egységteszthez speciális funkciókra van szükség – például a könyvtár „nem magányos” módba állítása és a tesztek egymástól való teljes elkülönítése.
- A kész program tesztelésének speciális taktikája szükséges, mert még a „legegyszerűbb indíthatóság” fogalma is eltűnik, mert az indíthatóság a konfigurációtól függ.
3.2 Gyári [módszer]
A gyári metódus egy általános tervezési minta, amely az alosztályok (osztályok örökösei) számára interfészt biztosít egy bizonyos osztály példányainak létrehozásához. A létrehozáskor a leszármazottak meghatározhatják, hogy melyik osztályt hozzanak létre.
Más szóval, ez a sablon az objektumok létrehozását a szülő osztály leszármazottaira ruházza. Ez lehetővé teszi, hogy a programkódban ne konkrét osztályokat használjunk, hanem az absztrakt objektumokat magasabb szinten kezeljük.
Ez a minta interfészt definiál egy objektum létrehozásához, de az alosztályokra bízza, hogy eldöntsék, melyik osztályra alapozzák az objektumot. A gyári metódus lehetővé teszi egy osztály számára, hogy delegálja az alosztályok létrehozását. Amikor:
- az osztály nem tudja előre, hogy mely alosztályok melyik objektumait kell létrehoznia.
- egy osztály úgy van kialakítva, hogy az általa létrehozott objektumokat alosztályok határozzák meg.
- az osztály a feladatait a több segítő alosztály valamelyikére delegálja, és a tervek szerint meghatározzák, melyik osztály veszi át ezeket a feladatokat.
3.3 Absztrakt gyár
Az absztrakt gyár egy általános tervezési minta, amely interfészt biztosít a kapcsolódó vagy egymástól függő objektumok családjainak létrehozásához anélkül, hogy megadná konkrét osztályaikat.
A mintát egy Factory absztrakt osztály létrehozásával valósítjuk meg, amely egy felület a rendszerkomponensek létrehozásához (például ablakfelülethez ablakokat és gombokat hozhat létre). Ezután olyan osztályokat írnak, amelyek megvalósítják ezt a felületet.
Olyan esetekben használatos, amikor a programnak függetlennek kell lennie a létrehozott új objektumok folyamatától és típusától. Amikor összefüggő objektumok családjait vagy csoportjait kell létrehozni, kizárva az ezek különböző halmazaiból származó objektumok egyidejű használatának lehetőségét ugyanabban a kontextusban.
Erősségek:
- elkülöníti az egyes osztályokat;
- leegyszerűsíti a termékcsaládok cseréjét;
- garantálja a termék kompatibilitását.
Tegyük fel, hogy a programod működik a fájlrendszerrel. Ezután a Linuxban való munkához LinuxFile, LinuxDirectory, LinuxFileSystem objektumok szükségesek. A Windwosban való munkához pedig a WindowsFile, WindowsDirectory, WindowsFileSystem osztályokra van szükség.
A Path osztály, amely a Path.of() segítségével jön létre, pont ilyen eset. A Path valójában nem egy osztály, hanem egy interfész, és WindowsPath és LinuxPath megvalósításokkal rendelkezik. És hogy milyen objektum jön létre, az el van rejtve a kódban, és futás közben fog eldőlni.
3.4 Prototípus
A prototípus egy generatív tervezési minta.
Ez a minta határozza meg a prototípuspéldány használatával létrehozott objektumok típusait, és ennek a prototípusnak a másolásával hoz létre új objektumokat. Lehetővé teszi, hogy elszakadjon a megvalósítástól, és kövesse az „interfészeken keresztül történő programozás” elvét.
A hierarchia tetején lévő interfész/absztrakt osztály van megadva visszatérő típusként, és a leszármazott osztályok helyettesíthetik azt az örököst, amely ezt a típust megvalósítja. Egyszerűen fogalmazva, ez egy objektum létrehozásának mintája egy másik objektum klónozásával, ahelyett, hogy egy konstruktoron keresztül hozná létre.
A mintát a következőkre használják:
- elkerülve az objektum szabványos módon történő létrehozásának további erőfeszítéseit (értsd: konstruktor használatával, mivel ebben az esetben a teljes objektum őshierarchiájának konstruktorait is meghívjuk), amikor ez az alkalmazás számára megfizethetetlenül költséges.
- kerülje az objektum létrehozójának öröklését az ügyfélalkalmazásban, ahogy az absztrakt gyári minta teszi.
Használja ezt a tervezési mintát, ha a programnak nem mindegy, hogyan hozza létre, állítja össze és prezentálja a termékeket:
- a példányosított osztályokat futási időben határozzák meg, például dinamikus betöltés segítségével;
- szeretné elkerülni az osztály- vagy gyári hierarchiák párhuzamos felépítését a termékosztály-hierarchiákkal;
- Az osztálypéldányok többféle állapotúak lehetnek. Kényelmesebb lehet a megfelelő számú prototípus beállítása és klónozása, ahelyett, hogy minden alkalommal manuálisan példányosítanánk az osztályt a megfelelő állapotban.