Návrhové vzory jsou úrovně návrhu řešení pro opakující se problémy, které jsme softwarových inženýrů narazit často. Není to kód-opakuji, kód. Je to jako popis, jak tyto problémy řešit a navrhnout řešení.
použití těchto vzorů je považováno za dobrou praxi, protože návrh řešení je poměrně vyzkoušen a testován, což vede k vyšší čitelnosti konečného kódu., Návrhové vzory jsou poměrně často vytvářeny a používány jazyky OOP, jako je Java,ve kterých bude napsána většina příkladů odtud.
typy návrhových vzorů
V současné době je objeveno asi 26 vzorů (stěží si myslím, že je udělám všechny…).
těchto 26 lze rozdělit do 3 typů:
1. Creational: tyto vzory jsou určeny pro instanci třídy. Mohou to být buď vzory vytváření tříd nebo vzory vytváření objektů.
2. Strukturální: tyto vzory jsou navrženy s ohledem na strukturu a složení třídy., Hlavním cílem většiny těchto vzorů je zvýšit funkčnost příslušné třídy (es), aniž by se změnila velká část jejího složení.
3. Behaviorální: tyto vzorce jsou navrženy v závislosti na tom, jak jedna třída komunikuje s ostatními.
v tomto příspěvku projdeme jeden základní návrhový vzor pro každý klasifikovaný Typ.
Typ 1: Creational – Singleton návrhový Vzor
Singleton návrhový Vzor je Creational vzor, jehož cílem je vytvořit pouze jednu instanci třídy a poskytovat pouze jednu globální přístupový bod k objektu., Jedním z běžně používaných příkladů takové třídy v Javě je kalendář, kde nemůžete vytvořit instanci této třídy. Používá také vlastní metodu getInstance(), aby získal objekt, který má být použit.
třídy pomocí singleton návrhový vzor bude zahrnovat,
- privátní statické proměnné, drží pouze instance třídy.
- soukromý Konstruktor, takže jej nelze instalovat nikde jinde.
- veřejná statická metoda pro návrat jedné instance třídy.,
existuje mnoho různých implementací singleton designu. Dnes budu procházet implementacemi;
1. Dychtivá instance
2. Lazy Instantiation
3. Thread-safe Instance
horlivci
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;}}Tento typ instance se stane během načítání tříd, jako instance proměnné instance se děje mimo jakýkoliv způsob. To představuje velkou nevýhodu, pokud tuto třídu klientská aplikace vůbec nepoužívá. Pohotovostní plán, pokud se tato třída nepoužívá, je líná instance.,
Lazy Days
není velký rozdíl od výše uvedené implementace. Hlavní rozdíly jsou, že statická proměnná je nejprve prohlásil, null, a je pouze vytvořena v rámci getInstance() metodu, pokud – a pouze pokud – proměnné instance zůstává null v době kontroly.
to řeší jeden problém, ale další stále existuje. Co když dva různí klienti přistupují ke třídě Singleton současně, přímo do milisekundy?, No, budou zkontrolujte, zda je instance null ve stejnou dobu, a bude to pravda, a tak vytvoří dvě instance třídy pro každou žádost dva klienty. Chcete-li to opravit, je třeba implementovat bezpečnou instanci podprocesu.
(Závit) Bezpečnost je Klíč
V jazyce Java, klíčové slovo synchronized se používá na metody nebo objekty implementovat bezpečnost podprocesu, tak, že pouze jedno vlákno bude přístup k určitému zdroji najednou. Instance třídy je umístěna v synchronizovaném bloku, takže metoda může být přístupná pouze jednomu klientovi v daném čase.,
režie synchronizované metody je vysoká a snižuje výkon celé operace.
například, pokud proměnné instance již vytvořena, pak pokaždé, když klient přistupuje getInstance() způsob, synchronized metoda je spustit a výkon klesá. K tomu dochází pouze za účelem kontroly, zda hodnota proměnných instance je nulová. Pokud zjistí, že je, opustí metodu.
pro snížení této režie se používá dvojité zamykání., Kontrola se používá před metodou synchronized a pokud je hodnota nulová, provede se metoda synchronized.
nyní na další klasifikaci.
Typ 2: Strukturální – Dekoratér Design Vzor
dám vám malý scénář pro lepší kontext, proč a kde byste měli použít Vzor Dekorátor.
Řekněme, že vlastníte kavárnu a jako každý nováček začínáte jen se dvěma druhy obyčejné kávy, domácí směsí a tmavou pečenou., Ve vašem fakturačním systému, tam byla jedna třída pro různé kávové směsi, který zdědí nápoj abstraktní třídy. Lidé skutečně začínají přijít a mají své nádherné (i když hořké?) káva. Pak jsou tu kávové nováčky, které, nedej bože, chtějí cukr nebo mléko. Taková parodie na kávu!! ??
nyní musíte mít také tyto dva doplňky, a to jak do nabídky, tak bohužel do fakturačního systému. Původně vaše IT osoba vytvoří podtřídu pro obě kávy, jednu včetně cukru, druhou mléko., Pak, protože zákazníci mají vždy pravdu, jeden říká Tato obávaná slova:
“ mohu dostat mléčnou kávu s cukrem, prosím?“
???
váš fakturační systém se opět směje do tváře. No, zpět na rýsovací prkno….
IT osoba pak přidává mléčnou kávu s cukrem jako další podtřídu do každé třídy mateřské kávy. Zbytek měsíce je hladká plachtění, lidé se připravují na kávu, vlastně vyděláváte peníze. ??
ale počkejte, je toho víc!
svět je opět proti vám., Soutěžící se otevírá přes ulici, nejen se 4 druhy kávy, ale také více než 10 doplňků! ?
koupíte všechny ty a další, prodáváte lepší kávu sami, a pak si pamatujte, že jste zapomněli aktualizovat tento dratted fakturační systém. Docela možná nemůžete vytvořit nekonečný počet podtříd pro všechny kombinace všech doplňků, s novými kávovými směsmi. Nemluvě o velikosti konečného systému.??
čas skutečně investovat do správného fakturačního systému., Najdete nové pracovníky, kteří skutečně ví, co dělají a říkají,
„Proč, to bude tak mnohem jednodušší a menší, pokud je použit vzor dekorátor.“
co to proboha je?
návrhový vzor dekorátoru spadá do konstrukční kategorie, která se zabývá skutečnou strukturou třídy, ať už je to dědičnost, složení nebo obojí. Cílem tohoto návrhu je upravit funkčnost objektů za běhu. To je jeden z mnoha dalších návrhových vzorů, které využívají abstraktní třídy a rozhraní s kompozicí, aby získaly požadovaný výsledek.,
dejme matematice šanci (chvěje se?), aby to všechno do perspektivy;
vezměte 4 kávové směsi a 10 doplňků. Pokud jsme se drželi generování podtříd pro každou jinou kombinaci všech doplňků pro jeden typ kávy. To je;
² 10-1) 2 = 92 = 81 podtříd
odečteme 1 z 10, protože nemůžete kombinovat jeden doplněk s jiným stejného typu, cukr s cukrem zní hloupě. A to jen na jednu kávovou směs. Vynásobte to 81 na 4 a dostanete neuvěřitelných 324 různých podtříd!, Mluvte o tom všem kódování …
ale s dekorátorovým vzorem bude v tomto scénáři vyžadovat pouze 16 tříd. Chceš se vsadit?
Pokud zmapujeme náš scénář podle diagramu tříd výše, máme 4 třídy pro 4 kávové směsi, 10 pro každý add-on a 1 pro abstraktní složka a 1 více za abstraktní malíř. Vidíš! 16!, Teď předej těch 100 dolarů.?? (jk, ale nebude to odmítnuto, pokud bude dáno… jen říkám)
jak můžete vidět shora, stejně jako betonové kávové směsi jsou podtřídy nápojové abstraktní třídy, třída addon abstract z ní také dědí své metody. Doplňky, které jsou jeho podtřídy, zase zdědí všechny nové metody pro přidání funkčnosti do základního objektu v případě potřeby.
pojďme se dostat k kódování, abychom viděli tento použitý vzor.,
První Abstraktní nápoj třídy, že všechny různé kávové směsi zdědí od:
Pak přidat i konkrétní káva směs třídy.
abstraktní třída AddOn také dědí z nápojové abstraktní třídy (více o tom níže).
A teď konkrétní implementace této abstraktní třídy:
Jak můžete vidět výše, můžeme předat jakékoliv podtřídy Nápoj na jakékoliv podtřídy AddOn, a získat další náklady, stejně jako aktualizovaný popis. A protože třída AddOn je v podstatě typu nápoje, můžeme předat AddOn do jiného addonu., Tímto způsobem můžeme přidat libovolný počet doplňků do konkrétní směsi kávy.
nyní napište nějaký kód, abyste to vyzkoušeli.
konečný výsledek je:
To funguje! Do kávové směsi jsme mohli přidat více než jeden doplněk a úspěšně aktualizovat její konečné náklady a popis, aniž bychom museli vytvářet nekonečné podtřídy pro každou doplňkovou kombinaci pro všechny kávové směsi.
konečně do poslední kategorie.,
typ 3: Behavioral-vzor návrhu příkazu
vzor návrhu chování se zaměřuje na to, jak třídy a objekty vzájemně komunikují. Hlavním zaměřením příkazového vzoru je vštípit vyšší stupeň volné vazby mezi zúčastněnými stranami (čti: třídy).
Uhhhh… co to je?
spojka je způsob, jakým dvě (nebo více) tříd, které vzájemně interagují, dobře interagují. Ideální scénář, kdy tyto třídy interagují, spočívá v tom, že na sobě nezávisí. To je volná spojka., Takže lepší definice pro volné spojení by byla, třídy, které jsou vzájemně propojeny, takže se navzájem nejméně využívají.
potřeba tohoto vzoru vznikla, když bylo třeba odeslat žádosti, aniž byste vědomě věděli, o co žádáte nebo kdo je přijímač.
v tomto vzoru je třída vyvolání oddělena od třídy, která skutečně provádí akci. Třída invoker má pouze metodu callable execute, která spustí potřebný příkaz, když o to klient požádá.
Vezměme si základní příklad v reálném světě a objednáme si jídlo v luxusní restauraci., Jak tok jde, dáte objednávku (příkaz) číšníkovi(invoker), který ji pak předá šéfkuchaři (přijímači), takže můžete získat jídlo. Může to znít jednoduše… ale trochu meh na kód.
myšlenka je velmi jednoduchá, ale kódování jde kolem nosu.,
flow z provozu po technické stránce je, aby konkrétní příkaz, který implementuje Příkaz rozhraní, žádá příjemce, aby dokončit akci, a poslat příkaz k vyvolávač. Invoker je osoba, která ví, kdy dát tento příkaz. Šéfkuchař je jediný, kdo ví, co dělat, když dostane konkrétní příkaz/objednávku., Když je tedy spuštěna metoda execute of the invoker, způsobí to, že metoda execute objective příkaz objects běží na přijímači, čímž dokončí potřebné akce.,
Co musíme provést, je;
- rozhraní Příkazového
- třída Řádu, který implementuje Příkaz rozhraní
- třída Číšník (vyvolávač)
- class Chef (přijímač)
, kódování vypadá takto:
Kuchař, přijímač
Příkaz, rozhraní
public interface Command {public abstract void execute();}Pořadí, konkrétní příkaz
Číšník, vyvolávač
public class Waiter {private Order order;public Waiter(Order ord) {this.order = ord;}public void execute() {this.order.execute();}}klient
Jak můžete vidět výše, Klient vydá Příkaz a nastaví Přijímač jako Kuchař., Objednávka je zaslána číšníkovi, který bude vědět, kdy provést objednávku (tj. kdy dát kuchaři příkaz k vaření). Při spuštění invokeru se na přijímači spustí metoda spouštění příkazů (tj. kuchař dostane příkaz buď vařit těstoviny ? nebo péct dort?).,
Rychlé shrnutí
V tomto příspěvku jsme šli přes:
- Co to návrhový vzor je opravdu,
- různé typy návrhových vzorů a proč jsou různé
- základní nebo společný návrhový vzor pro každý typ
doufám, že to bylo užitečné.
najděte kód repo pro příspěvek zde.