a tervezési minták tervezési szintű megoldások az ismétlődő problémákra, amelyekkel mi szoftvermérnökök gyakran találkozunk. Ez nem Kód – ismétlem, ❌kód. Ez olyan, mint egy leírást, hogyan kell kezelni ezeket a problémákat, és tervezzen megoldást.
ezeknek a mintáknak a használata jó gyakorlatnak tekinthető, mivel a megoldás kialakítása meglehetősen kipróbált és tesztelt, ami a végső kód nagyobb olvashatóságát eredményezi., A tervezési mintákat gyakran az OOP nyelvekhez, például a Java nyelvekhez hozzák létre és használják, ahol a legtöbb példát innen írják.
tervezési minták típusai
jelenleg körülbelül 26 mintát fedeznek fel (alig hiszem, hogy mindent megteszek…).
Ez a 26 típus 3 típusba sorolható:
1. Creational: ezeket a mintákat az osztály példányosítására tervezték. Ezek lehetnek osztály-létrehozási minták vagy objektum-teremtési minták.
2. Szerkezeti: ezeket a mintákat egy osztály szerkezetére és összetételére tekintettel tervezték., A legtöbb ilyen minta fő célja az érintett osztály(ok) funkcionalitásának növelése anélkül, hogy összetételének nagy részét megváltoztatná.
3. Viselkedés: ezeket a mintákat attól függően tervezték, hogy az egyik osztály hogyan kommunikál másokkal.
ebben a bejegyzésben minden egyes Osztályozott típushoz egy alapvető tervezési mintát fogunk átmenni.
Type 1: Creational – The Singleton Design Pattern
a Singleton Design Pattern egy Creational pattern, amelynek célja egy osztály egyetlen példányának létrehozása, és hogy csak egy globális hozzáférési pontot biztosítson az objektumhoz., Egy általánosan használt példa egy ilyen osztály Java naptár, ahol nem lehet, hogy egy példány, hogy az osztály. Azt is használja a saját getInstance()módszer, hogy az objektumot kell használni.
egy osztály a singleton tervezési minta tartalmazza,
- egy privát statikus változó, kezében az egyetlen példány az osztály.
- egy privát konstruktor, így máshol nem lehet példányosítani.
- public static method, to return the single instance of the class.,
sok különböző megvalósítások singleton design. Ma, én lesz megy keresztül a megvalósítások;
1. Eager Instantiation
2. Lusta példányosítás
3. Thread-safe Instantiation
Eager Beaver
public class EagerSingleton {// create an instance of the class.private static EagerSingleton instance = new EagerSingleton();// private constructor, so it cannot be instantiated outside this class.private EagerSingleton() { }// get the only instance of the object created.public static EagerSingleton getInstance() {return instance;}}Ez a fajta példányosítás történik az osztály betöltése során, mivel a változó példányának példányosítása bármely módszeren kívül történik. Ez komoly hátrányt jelent, ha ezt az osztályt egyáltalán nem használja az ügyfélalkalmazás. A készenléti terv, ha ezt az osztályt nem használják, a lusta példányosítás.,
lusta napok
nincs sok különbség a fenti végrehajtástól. A fő különbség az, hogy a statikus változó kezdetben null, és csak a getInstance() metóduson belül jelenik meg, ha – és csak akkor, ha – a példányváltozó null marad az ellenőrzés idején.
Ez megoldja az egyik problémát, de egy másik még mindig létezik. Mi van, ha két különböző ügyfél egyszerre fér hozzá a Singleton osztályhoz, közvetlenül a milliszekundumig?, Nos, ellenőrzik, hogy a példány egyszerre null-e, és igaznak találják-e, így a két ügyfél minden egyes kérésére két osztálypéldányt hoz létre. Ennek javításához a szál biztonságos példányosítását végre kell hajtani.
(Thread) biztonság kulcs
Java-ban a szinkronizált kulcsszót módszereken vagy objektumokon használják a szálbiztonság megvalósításához, így egyszerre csak egy szál fér hozzá egy adott erőforráshoz. Az osztály példányosítás egy szinkronizált blokkba kerül, így a módszer csak egy ügyfél számára érhető el egy adott időpontban.,
a szinkronizált módszer felső értéke magas, ami csökkenti az egész művelet teljesítményét.
például, ha a példányváltozó már példányosításra került, akkor minden alkalommal, amikor bármely ügyfél hozzáfér a getInstance()metódushoz, a synchronized metódus fut, és a teljesítmény csökken. Ez csak azért történik, hogy ellenőrizze ,hogy ainstance változók értéke null. Ha úgy találja, hogy az, elhagyja a módszert.
a rezsi csökkentése érdekében kettős reteszelést használnak., Az ellenőrzést a synchronized metódus előtt is használják, és ha az érték önmagában null, akkor a synchronized metódus fut.
most a következő osztályozásra.
Type 2: Structural-The Decorator Design Pattern
adok egy kis forgatókönyv, hogy egy jobb összefüggésben, hogy miért és hol kell használni a lakberendező Minta.
azt mondják, hogy van egy kávézód, és mint minden újonc, csak kétféle sima kávéval kezded, a ház keverékével és a sötét sülttel., A számlázási rendszer, volt egy osztály a különböző kávé keverékek, amely örökli az ital absztrakt osztály. Az emberek valóban elkezd jönni, és van a csodálatos (bár keserű?) kávé. Aztán ott vannak a kávéfőzők, amelyek, Isten ments, cukrot vagy tejet akarnak. Egy ilyen travesty kávé!! ??
most meg kell adnod ezt a két kiegészítőt is, mind a menübe, mind sajnos a számlázási rendszerbe. Eredetileg az informatikai személy mindkét kávéhoz alosztályt készít, az egyik a cukrot, a másik a tejet., Akkor, mivel az ügyfeleknek mindig igaza van, ezeket a rettegett szavakat mondja:
“kaphatok egy tejes kávét cukorral, kérem?”
???
ott megy a számlázási rendszer nevetve az arcod újra. Nos, vissza a rajztáblához….
az informatikai személy ezután a tejes kávét cukorral egészíti ki, mint egy másik alosztályt minden szülő kávéosztályhoz. A hónap többi része sima vitorlázás,az emberek sorakoznak, hogy a kávé, akkor valóban pénzt. ??
de várj, van még!
a világ ismét ellened van., A versenytárs nyílik az utca túloldalán, nem csak 4 típusú kávé, de több mint 10 kiegészítők is! ?
mindent megvásárol, hogy jobb kávét adjon el magának, majd ne feledje, hogy elfelejtette frissíteni a dratted számlázási rendszert. Valószínűleg nem teheti meg a végtelen számú alosztályt az összes kiegészítő kombinációjához, az új kávékeverékekkel is. Nem is beszélve a végleges rendszer méretéről.??
ideje, hogy ténylegesen befektetni a megfelelő számlázási rendszer., Talál új IT személyzet, aki valóban tudja, mit csinálnak, és azt mondják;
” miért, ez sokkal könnyebb és kisebb lesz, ha a dekorációs mintát használja.”
mi a fene ez?
a dekorátor tervezési mintája a szerkezeti kategóriába tartozik, amely egy osztály tényleges szerkezetével foglalkozik, akár öröklés, akár összetétel, akár mindkettő. Ennek a kialakításnak az a célja, hogy futásidőben módosítsa az objektumok funkcionalitását. Ez az egyik a sok más tervezési minták, hogy kihasználja absztrakt osztályok, interfészek kompozíció, hogy a kívánt eredményt.,
adjunk matematikai esélyt (borzongás?) mindezt szem előtt tartva;
vegyen be 4 kávékeveréket és 10 kiegészítőt. Ha ragaszkodunk az alosztályok generációjához az összes kiegészítő minden egyes kombinációjához egy típusú kávéhoz. Ez;
(10-1)2 = 92 = 81 alosztályok
kivonunk 1-et a 10-ből, mivel nem lehet egyetlen kiegészítőt kombinálni egy másik azonos típusú cukorral, a cukor hülyén hangzik. És ez csak egy kávékeverékre vonatkozik. Szorozzuk meg a 81-et 4-gyel, és kapsz egy óriási 324 különböző alosztályt!, Beszélj az összes kódolásról …
de a dekorátor mintával csak 16 osztály szükséges ebben a forgatókönyvben. Akarsz fogadni?
Ha a térképet a forgatókönyv szerint az osztály a fenti ábrát, kapunk 4 osztályok a 4 kávé keverékek, 10 az egyes add-on, 1 az absztrakt alkatrész, 1 nagyobb az absztrakt festő. Látod! 16!, Add ide azt a 100 dollárt.?? (jk, de nem fogják megtagadni, ha megadják… csak azt mondom)
amint fent látható, csakúgy, mint a beton kávékeverékek az ital absztrakt osztály alosztályai, az AddOn absztrakt osztály is örökölte módszereit. A bővítmények, amelyek alosztályai, viszont örökölnek minden új módszert, hogy szükség esetén funkcionalitást adjunk az alapobjektumhoz.
menjünk a kódoláshoz, hogy lássuk ezt a mintát a használatban.,
először, hogy az absztrakt ital osztály, hogy az összes különböző kávé keverékek örökli:
majd hozzá mind a beton kávé keverék osztályok.
az AddOn absztrakt osztály is örökli az ital absztrakt osztály (erről bővebben alább).
és most ennek az absztrakt osztálynak a konkrét implementációi:
amint fent látható, az ital bármely alosztályát átadhatjuk az AddOn bármely Alosztályának, valamint megkaphatjuk a hozzáadott költségeket, valamint a frissített leírást. Mivel az AddOn osztály lényegében ital típusú, egy addont át tudunk adni egy másik Addonba., Ily módon tetszőleges számú kiegészítőt hozzáadhatunk egy adott kávékeverékhez.
most, hogy írjon egy kódot, hogy tesztelje ezt.
a végeredmény:
működik! Több kiegészítőt is hozzá tudtunk adni egy kávékeverékhez, és sikeresen frissítettük a végső költségét és leírását, anélkül, hogy végtelen alosztályokat kellett volna készítenünk minden egyes kiegészítő kombinációhoz minden kávékeverékhez.
végül az utolsó kategóriába.,
3. Típus: Behavioral – a
parancstervezési minta arra összpontosít, hogy az osztályok és objektumok hogyan kommunikálnak egymással. A fő hangsúly a parancs minta, hogy inculcate magasabb fokú laza kapcsolási érintett felek között (olvas: osztályok).
Uhhhh … mi ez?
A kapcsolás az, ahogyan két (vagy több) osztály kölcsönhatásba lép egymással, nos, kölcsönhatásba lép. Az ideális forgatókönyv, amikor ezek az osztályok kölcsönhatásba lépnek, az, hogy nem függenek nagymértékben egymástól. Ez laza kapcsolás., Tehát a laza tengelykapcsoló jobb meghatározása az összekapcsolt osztályok, amelyek a legkevésbé használják egymást.
ennek a mintának a szükségessége akkor merült fel, amikor kéréseket kellett küldeni anélkül, hogy tudatosan tudnánk, mit kér, vagy ki a vevő.
ebben a mintában a meghívó osztály függetlenül attól az osztálytól, amely ténylegesen végrehajtja a műveletet. A számlázó osztály csak a hívható módszer végrehajtásával rendelkezik, amely a szükséges parancsot futtatja, amikor az ügyfél kéri.
Vegyünk egy alapvető valós példát, rendeljünk ételt egy divatos étteremben., Ahogy az áramlás megy, adja meg megrendelését (parancs) a pincérnek(invoker), aki ezt követően átadja a séfnek (Vevőnek), így ételt kaphat. Lehet, hogy egyszerűnek hangzik … de egy kicsit meh a kódhoz.
az ötlet nagyon egyszerű, de a kódolás az orr körül megy.,
a működési folyamat a technikai oldalon, hogy egy konkrét parancsot, amely végrehajtja a parancs interfész, kérve a vevő, hogy befejezze a műveletet, és küldje el a parancsot a számlázó. A számlázó az a személy, aki tudja, mikor adja meg ezt a parancsot. A séf az egyetlen, aki tudja, mit kell tennie, ha megadja az adott parancsot/megrendelést., Tehát, amikor a számlázó végrehajtási módszere fut, ez viszont azt eredményezi, hogy a parancsobjektumok végrehajtási módszere fut a vevőn, így végrehajtja a szükséges műveleteket.,
Mi kell végrehajtani;
- Egy felület Parancs
- Egy osztály Érdekében, hogy végrehajtja a Parancsot felület
- Egy osztály Pincér (invoker)
- A class Chef (vevő)
Szóval, a kódolás megy, mint ez:
Szakács, a vevő
Parancs, a felület
public interface Command {public abstract void execute();}Rend, a konkrét parancs
Pincér, a invoker
public class Waiter {private Order order;public Waiter(Order ord) {this.order = ord;}public void execute() {this.order.execute();}}A, az ügyfél
Mint látható a fenti, az Ügyfél teszi a Parancs beállítja a Vevő, mint a Szakács., A megrendelést a pincérnek küldjük, aki tudni fogja, mikor kell végrehajtani a megrendelést (azaz mikor kell a szakácsnak a szakácsot főzni). Amikor a számlázó végrehajtásra kerül, a megrendelések végrehajtási módszere fut a vevőn (azaz a szakács megkapja a parancsot, hogy vagy tésztát főzzön ? vagy süteményt sütni?).,
gyors recap
ebben a bejegyzésben átmentünk:
- mi a tervezési minta valójában,
- a különböző tervezési minták és miért különböznek egymástól
- egy alapvető vagy közös tervezési minta minden típushoz
remélem, hogy ez hasznos volt.
keresse meg a kód repo a post, itt.