Štát. Štátne triedy pre každý štát

Samozrejme, toto nie je jediný spôsob implementácie hierarchie. Ale ak nepoužijete šablónu Gang of Four State, nebude to fungovať. Namiesto toho môžete modelovať jasnú hierarchiu súčasných štátov a superštátov stoh stavov namiesto jedného stavu v hlavnej triede.

Aktuálny stav bude v hornej časti zásobníka, pod ním je jeho superstav, potom superstav pre toto superštáty atď. A keď potrebujete implementovať správanie špecifické pre stav, začnete od vrcholu zásobníka a postupujete smerom nadol, kým to daný stav nespracuje. (A ak to nespracuje, potom to jednoducho ignorujete).

Automat s pamäťou zásobníka

Existuje ďalšie bežné rozšírenie stavových automatov, ktoré tiež používa zásobník stavov. Len tu zásobník predstavuje úplne iný koncept a používa sa na riešenie iných problémov.

Problém je v tom, že štátny automat nemá koncepciu príbehov. Vieš v akom si stave? si, ale nemáte informácie o tom, v akom stave sa nachádzate boli. A preto neexistuje jednoduchý spôsob, ako sa vrátiť do predchádzajúceho stavu.

Tu je jednoduchý príklad: Predtým sme našej nebojácnej hrdinke dovolili, aby sa vyzbrojila po zuby. Keď vystrelí zo zbrane, potrebujeme nový stav, aby sme prehrali animáciu výstrelu, splodili guľku a sprievodné vizuálne efekty. Aby sme to urobili, vytvoríme nový FiringState a urobíme doň prechody zo všetkých stavov, v ktorých môže hrdinka strieľať stlačením tlačidla streľby.

Keďže toto správanie je duplikované medzi viacerými stavmi, tu je možné použiť hierarchický stavový automat na opätovné použitie kódu.

Problém je v tom, že musíte nejako pochopiť, do akého stavu musíte ísť. po Streľba. Hrdinka môže odpáliť celý klip, zatiaľ čo stojí, behá, skáče alebo sa krčí. Po dokončení sekvencie streľby sa musí vrátiť do stavu, v akom bola pred streľbou.

Ak sa pripútame k čistému FSM, okamžite zabudneme, v akom stave sme boli. Aby sme to mali prehľad, musíme definovať veľa takmer identických stavov – streľba v stoji, streľba v behu, streľba zo skoku atď. Máme teda pevne zakódované prechody, ktoré po dokončení prejdú do správneho stavu.

To, čo skutočne potrebujeme, je možnosť uložiť si stav, v ktorom sme boli pred streľbou, a po streľbe si ho znova zapamätať. Tu nám opäť môže pomôcť teória automatov. Zodpovedajúca dátová štruktúra sa nazýva Pushdown Automaton.

Kde v konečnom automate máme jediný ukazovateľ na stav, v automate s pamäťou je ich stoh. V MFŠ prechod do nového stavu nahrádza predchádzajúci. Stroj s pamäťou zásobníka vám to tiež umožňuje, ale pridáva ďalšie dve operácie:

Môžeš miesto (TAM) nový stav do zásobníka. Aktuálny stav bude vždy na vrchole zásobníka, takže ide o operáciu prechodu do nového stavu. Zároveň však starý stav zostáva priamo pod súčasným stavom zásobníka a nezmizne bez stopy.

Môžeš extrakt (pop) najvyšší stav zo zásobníka. Štát zaniká a to, čo bolo pod ním, sa stáva aktuálnym.

To je všetko, čo k streľbe potrebujeme. Tvoríme jediná vec strelecký stav. Keď stlačíme tlačidlo streľby v inom stave, my miesto (TAM) stav snímania zásobníka. Keď skončí animácia streľby, my extrakt (pop) a stroj s pamäťou zásobníka nás automaticky vráti do predchádzajúceho stavu.

Nakoľko sú skutočne užitočné?

Aj pri tomto rozšírení štátnych automatov sú ich možnosti stále dosť obmedzené. V AI dnes prevláda trend používať veci ako stromy správania(stromy správania) a plánovacie systémy(plánovacie systémy). A ak sa obzvlášť zaujímate o oblasť AI, celá táto kapitola by vám mala nahnať chuť do jedla. Aby ste ho uspokojili, budete sa musieť obrátiť na iné knihy.

To vôbec neznamená, že konečné automaty, automaty s pamäťou zásobníka a iné podobné systémy sú úplne zbytočné. Pre niektoré veci sú to dobré modelovacie nástroje. Stavové automaty sú užitočné, keď:

• Máte entitu, ktorej správanie sa mení v závislosti od jej vnútorného stavu.
• Táto podmienka je striktne rozdelená na relatívne malý počet konkrétnych možností.
• Entita neustále reaguje na sériu vstupných príkazov alebo udalostí.

V hrách sa stavové automaty zvyčajne používajú na modelovanie AI, ale môžu sa použiť aj na implementáciu používateľského vstupu, navigácie v ponuke, analýzy textu, sieťových protokolov a iného asynchrónneho správania.

Stav je vzor správania sa objektu, ktorý špecifikuje rôzne funkcie v závislosti od vnútorného stavu objektu. pôvodný zdroj webovej stránky

Podmienky, úloha, účel

Motivácia

Hlavnou myšlienkou tohto vzoru je predstaviť abstraktnú triedu TCPState reprezentovať rôzne stavy pripojenia. Táto trieda deklaruje rozhranie, ktoré je spoločné pre všetky triedy, ktoré popisujú rôznych pracovníkov. pôvodný zdroj.ru

stave. V týchto podtriedach TCPState implementuje sa správanie špecifické pre daný stav. Napríklad v triedach TCPEstablished A TCPClosed implementované správanie špecifické pre daný stav Založené A ZATVORENÉ resp. pôvodný zdroj webovej stránky

original.ru

Trieda TCPConnection ukladá objekt stavu (inštanciu podtriedy TCPState), ktorý predstavuje aktuálny stav pripojenia a deleguje všetky požiadavky závislé od stavu na tento objekt. TCPConnection používa vlastnú inštanciu podtriedy TCPState celkom jednoduché: volanie metód jedného rozhrania TCPState, len v závislosti od toho, aká konkrétna podtrieda je aktuálne uložená TCPState-a - výsledok je iný, t.j. v skutočnosti sa vykonávajú operácie, ktoré sú špecifické len pre tento stav pripojenia. zdroj original.ru

A zakaždým, keď sa zmení stav pripojeniaTCPConnection zmení svoj stavový objekt. Napríklad, keď sa nadviazané spojenie uzavrie, TCPConnection nahrádza inštanciu triedy TCPEstablished kopírovať TCPClosed. pôvodný zdroj stránky

Znaky aplikácie, použitie vzoru State

1. Keď správanie objektu závisí od jeho stavu a musí sa zmeniť za behu. zdroj original.ru
2. Keď operačný kód obsahuje podmienené príkazy pozostávajúce z mnohých vetiev, v ktorých výber vetvy závisí od stavu. Typicky je v tomto prípade stav reprezentovaný vymenovanými konštantami. Rovnaká štruktúra podmieneného príkazu sa často opakuje v niekoľkých operáciách. Vzor stavu navrhuje umiestniť každú vetvu do samostatnej triedy. To vám umožňuje považovať stav objektu za nezávislý objekt, ktorý sa môže meniť nezávisle od ostatných. zdroj lokality pôvodná lokalita

Riešenie

source.ru

Účastníci štátneho vzoru

1. Kontext(TCPConnection) - kontext.
   Definuje jediné rozhranie pre klientov.
   Ukladá inštanciu podtriedy ConcreteState, ktorý určuje aktuálny stav. kódové laboratórium.
2. Štát(TCPSate) - štát.
   Definuje rozhranie na zapuzdrenie správania spojeného s konkrétnym stavom kontextu. zdroj stránky pôvodný
3. Podtriedy ConcreteState(TCPEstablished, TCPListen, TCPClosed) - špecifický stav.
   Každá podtrieda implementuje správanie spojené s nejakým kontextovým stavom Kontext. pôvodný zdroj stránky

Schéma na použitie vzoru Stav

Kontext sa môže odovzdať ako argument objektu Štát, ktorá žiadosť spracuje. To umožňuje objektu stavu ( ConcreteState) v prípade potreby vstúpte do kontextu. kódové laboratórium.

Kontext- Toto je hlavné rozhranie pre klientov. Klienti môžu konfigurovať kontext pomocou stavových objektov Štát(presnejšie ConcreteState). Akonáhle je kontext nakonfigurovaný, klienti už nemusia komunikovať priamo so stavovými objektmi (iba cez spoločné rozhranie Štát). source.ru

V tomto prípade tiež Kontext alebo samotné podtriedy ConcreteState môže rozhodnúť, za akých podmienok a v akom poradí k zmene stavov dôjde. pôvodný zdroj webovej stránky

Otázky týkajúce sa implementácie štátneho vzoru

1. Čo určuje prechody medzi stavmi.
   Štátny vzorec nehovorí nič o tom, ktorý účastník určuje podmienky (kritériá) prechodu medzi štátmi. Ak sú kritériá pevne stanovené, môžu sa implementovať priamo v triede Kontext. Vo všeobecnosti je však flexibilnejší a správnejší prístup povoliť podtriedy samotnej triedy Štát určiť ďalší stav a moment prechodu. Aby ste to urobili v triede Kontext musíme pridať rozhranie, ktoré umožňuje z objektov Štát nastaviť jeho stav.
   Táto decentralizovaná prechodová logika sa ľahšie upravuje a rozširuje – stačí definovať nové podtriedy Štát. Nevýhodou decentralizácie je, že každá podtrieda Štát musí „vedieť“ aspoň o jednej podtriede iného stavu (do ktorého môže skutočne prepnúť aktuálny stav), čo zavádza implementačné závislosti medzi podtriedami. zdroj stránky pôvodný

   zdroj original.ru

2. Tabuľková alternatíva.
   Existuje ďalší spôsob, ako štruktúrovať štátom riadený kód. Toto je princíp konečného automatu. Používa tabuľku na mapovanie vstupov na prechody stavov. S jeho pomocou môžete určiť, do ktorého stavu musíte prejsť, keď prídu určité vstupné údaje. V podstate nahrádzame podmienený kód vyhľadávaním v tabuľke.
   Hlavnou výhodou stroja je jeho pravidelnosť: na zmenu kritérií prechodu stačí upraviť iba údaje, nie kód. Ale sú tu aj nevýhody:
   - vyhľadávanie v tabuľke je často menej efektívne ako volanie funkcie,
   - prezentácia logiky prechodu v jednotnom tabuľkovom formáte robí kritériá menej explicitnými, a preto sú ťažšie zrozumiteľné,
   - zvyčajne je ťažké pridať akcie, ktoré sprevádzajú prechody medzi stavmi. Tabuľková metóda zohľadňuje stavy a prechody medzi nimi, je však potrebné ju doplniť, aby bolo možné vykonávať ľubovoľné výpočty pri každej zmene stavu.
   Hlavný rozdiel medzi stavovými automatmi založenými na tabuľke a stavom vzoru možno formulovať takto: Stav vzoru modeluje správanie závislé od stavu a tabuľková metóda sa zameriava na definovanie prechodov medzi stavmi. original.ru

   pôvodný zdroj stránky

3. Vytváranie a ničenie štátnych objektov.
   Počas procesu vývoja si zvyčajne musíte vybrať medzi:
   - vytváranie stavových objektov, keď sú potrebné, a ich zničenie ihneď po použití,
   - ich vytváranie vopred a navždy.

   Prvá možnosť je vhodnejšia, keď nie je vopred známe, do akých stavov systém spadne, a kontext mení stav pomerne zriedka. Zároveň nevytvárame objekty, ktoré sa nikdy nepoužijú, čo je dôležité, ak je v stavových objektoch uložených veľa informácií. Keď sa zmeny stavu vyskytujú často, takže nechcete zničiť objekty, ktoré ich reprezentujú (pretože môžu byť čoskoro opäť potrebné), mali by ste použiť druhý prístup. Čas na vytváranie predmetov sa strávi iba raz, na samom začiatku, a čas na ničenie sa nestrávi vôbec. Je pravda, že tento prístup sa môže ukázať ako nepohodlný, pretože kontext musí uchovávať odkazy na všetky stavy, do ktorých by sa systém mohol teoreticky dostať. zdroj original.ru

   Pôvodný zdroj.ru

4. Použitie dynamických zmien.
   Je možné zmeniť správanie na požiadanie zmenou triedy objektu za behu, ale väčšina objektovo orientovaných jazykov to nepodporuje. Výnimkou je Perl, JavaScript a ďalšie jazyky založené na skriptovacích strojoch, ktoré poskytujú takýto mechanizmus, a preto podporujú stav vzoru priamo. To umožňuje objektom meniť svoje správanie zmenou kódu triedy. source.ru

   Pôvodný zdroj .ru

výsledky

1. Lokalizuje správanie závislé od stavu.
   A rozdeľuje ho na časti zodpovedajúce stavom. Vzor stavu dáva všetko správanie spojené s konkrétnym stavom do samostatného objektu. Pretože kód závislý od stavu je úplne obsiahnutý v jednej z podtried triedy Štát, potom môžete pridať nové stavy a prechody jednoducho vytvorením nových podtried.
   Namiesto toho by sa dali použiť dátové členy na definovanie vnútorných stavov a potom operácií objektu Kontext skontroluje tieto údaje. Ale v tomto prípade by podobné podmienené príkazy alebo príkazy vetvy boli rozptýlené po celom kóde triedy Kontext. Pridanie nového stavu by si však vyžiadalo zmenu viacerých operácií, čo by sťažilo údržbu. Stavový vzor rieši tento problém, ale vytvára aj ďalší, pretože správanie pre rôzne stavy je nakoniec rozdelené medzi niekoľko podtried Štát. Tým sa zvyšuje počet tried. Samozrejme, jedna trieda je kompaktnejšia, ale ak existuje veľa stavov, potom je takáto distribúcia efektívnejšia, pretože inak by sa museli zaoberať ťažkopádnymi podmienenými príkazmi.
   Ťažkopádne podmienené vyhlásenia sú nežiaduce, rovnako ako dlhé postupy. Sú príliš monolitické, a preto sa úprava a rozšírenie kódu stáva problémom. Vzor stavu ponúka lepší spôsob štruktúrovania kódu závislého od stavu. Logika popisujúca prechody stavov už nie je zabalená do monolitických príkazov ak alebo prepínač, ale distribuované medzi podtriedy Štát. Zapuzdrením každého prechodu a akcie do triedy sa štát stáva plnohodnotným objektom. To zlepšuje štruktúru kódu a sprehľadňuje jeho účel. original.ru
2. Zvýrazňuje prechody medzi stavmi.
   Ak objekt definuje svoj aktuálny stav výlučne z hľadiska interných údajov, potom prechody medzi stavmi nemajú žiadnu explicitnú reprezentáciu; objavujú sa len ako priradenia k určitým premenným. Zavedením samostatných objektov pre rôzne stavy sú prechody explicitnejšie. Okrem toho predmety Štát môže chrániť kontext Kontext z nesúladu vnútorných premenných, keďže prechody z hľadiska kontextu sú atomické akcie. Ak chcete vykonať prechod, musíte zmeniť hodnotu iba jednej premennej (objektovej premennej Štát v triede Kontext), a nie niekoľko. source.ru
3. Stavové objekty je možné zdieľať.
   Ak je v stave objektu Štát neexistujú žiadne premenné inštancie, čo znamená, že stav, ktorý predstavuje, je kódovaný výlučne samotným typom, potom môžu rôzne kontexty zdieľať rovnaký objekt Štát. Keď sú štáty oddelené týmto spôsobom, sú to v podstate oportunisti (pozri oportunistický vzorec), ktorí nemajú žiadny vnútorný stav, iba správanie. zdroj lokality pôvodná lokalita

Príklad

Najprv si definujme triedu TCPConnection, ktorý poskytuje rozhranie na prenos dát a spracováva požiadavky na zmenu stavu: TCPConnection. Pôvodný zdroj.ru

V členskej premennej štát trieda TCPConnection je uložená inštancia triedy TCPState. Táto trieda duplikuje rozhranie zmeny stavu definované v triede TCPConnection. zdroj original.ru

pôvodný zdroj stránky

TCPConnection deleguje všetky požiadavky závislé od stavu na inštanciu uloženú v stave TCPState. Aj v triede TCPConnection existuje operácia ChangeState, pomocou ktorého môžete do tejto premennej zapísať ukazovateľ na iný objekt TCPState. Konštruktor triedy TCPConnection inicializuje štát ukazovateľ do uzavretého stavu TCPClosed(definujeme to nižšie). zdroj original.ru

Pôvodný zdroj.ru

Každá operácia TCPState akceptuje inštanciu TCPConnection ako parameter, čím sa objekt povolí TCPState prístup k údajom objektu TCPConnection a zmeniť stav pripojenia. .ru

V triede TCPState implementoval predvolené správanie pre všetky požiadavky, ktoré mu boli delegované. Môže tiež zmeniť stav objektu TCPConnection cez operáciu ChangeState. TCPState nachádza v rovnakom balení ako TCPConnection, takže má tiež prístup k tejto operácii: TCPState . pôvodný zdroj stránky

original.ru

V podtriedach TCPState implementované správanie závislé od stavu. TCP spojenie môže byť v mnohých stavoch: Založené(nainštalované), Počúvanie(počúvanie), ZATVORENÉ(uzavreté) atď. a každý z nich má svoju vlastnú podtriedu TCPState. Pre jednoduchosť podrobne zvážime iba 3 podtriedy - TCPEstablished, TCPListen A TCPClosed. pôvodný zdroj webovej stránky

Zdroj Ru

V podtriedach TCPState implementuje správanie závislé od stavu pre tie požiadavky, ktoré sú v danom stave platné. .ru

pôvodný zdroj stránky

Po vykonaní akcií špecifických pre daný stav tieto operácie zdroj original.ru

spôsobiť ChangeState zmeniť stav objektu TCPConnection. On sám nemá informácie o protokole TCP. Ide o podtriedy TCPState definovať prechody medzi stavmi a akciami diktovanými protokolom. original.ru

zdroj original.ru

Známe aplikácie štátneho vzoru

Na vyjadrenie závislosti správania editora od aktuálneho nástroja môžete použiť vzor stavu. pôvodný zdroj.ru

Môžete definovať abstraktnú triedu Nástroj, ktorého podtriedy implementujú správanie špecifické pre nástroj. V grafickom editore je uložený odkaz na aktuálny objekt Tiežl a deleguje mu prichádzajúce požiadavky. Keď vyberiete nástroj, editor použije iný objekt, čo spôsobí zmenu správania. .ru

Táto technika sa používa v rámci grafických editorov HotDraw a Unidraw. Umožňuje zákazníkom jednoducho definovať nové typy nástrojov. IN HotDraw Trieda DrawingController preposiela požiadavky na aktuálny objekt Nástroj. IN Unidraw zodpovedajúce triedy sa nazývajú Divák A Nástroj. Nižšie uvedený diagram tried poskytuje schematické znázornenie rozhraní tried Nástroj

Účel štátneho vzoru

• Vzor Stav umožňuje objektu zmeniť svoje správanie v závislosti od jeho vnútorného stavu. Zdá sa, že objekt zmenil svoju triedu.
• Vzor Stav je objektovo orientovaná implementácia stavového automatu.

Problém, ktorý treba vyriešiť

Správanie objektu závisí od jeho stavu a musí sa meniť počas vykonávania programu. Takáto schéma môže byť implementovaná pomocou mnohých podmienených operátorov: na základe analýzy súčasného stavu objektu sa vykonajú určité akcie. Pri veľkom počte stavov však budú podmienené príkazy roztrúsené po celom kóde a takýto program bude náročný na údržbu.

Diskusia o štátnom vzore

Vzor štátu rieši tento problém takto:

• Zavádza triedu Context, ktorá definuje rozhranie k vonkajšiemu svetu.
• Predstavuje abstraktnú triedu State.
• Predstavuje rôzne "stavy" stavového automatu ako podtriedy stavu.
• Trieda Context má ukazovateľ na aktuálny stav, ktorý sa zmení, keď sa zmení stav stavového automatu.

Vzor stavu nedefinuje, kde presne je určená podmienka prechodu do nového stavu. Existujú dve možnosti: trieda Context alebo podtriedy State. Výhodou poslednej možnosti je jednoduché pridávanie nových odvodených tried. Nevýhodou je, že každá podtrieda štátu musí vedieť o svojich susedoch, aby mohla prejsť do nového stavu, čo zavádza závislosti medzi podtriedami.

Existuje aj alternatívny prístup založený na tabuľkách k navrhovaniu konečných automatov, založený na použití tabuľky, ktorá jedinečne mapuje vstupné dáta na prechody medzi stavmi. Tento prístup má však nevýhody: je ťažké pridať vykonávanie akcií pri vykonávaní prechodov. Prístup podľa vzoru stavu používa kód (namiesto dátových štruktúr) na prechody medzi stavmi, takže tieto akcie sa dajú ľahko pridať.

Štruktúra štátneho vzoru

Trieda Context definuje externé rozhranie pre klientov a ukladá odkaz na aktuálny stav objektu State. Rozhranie abstraktnej základnej triedy State je rovnaké ako rozhranie Context s výnimkou jedného dodatočného parametra - ukazovateľa na inštanciu Context. Triedy odvodené od stavu definujú správanie špecifické pre daný stav. Trieda Context wrapper deleguje všetky prijaté požiadavky na objekt "aktuálny stav", ktorý môže použiť prijatý dodatočný parameter na prístup k inštancii Context.

Vzor Stav umožňuje objektu zmeniť svoje správanie v závislosti od jeho vnútorného stavu. Podobný obraz možno pozorovať aj pri prevádzke predajného automatu. Stroje môžu mať rôzne stavy v závislosti od dostupnosti tovaru, množstva prijatých mincí, schopnosti zamieňať peniaze atď. Po vybratí a zaplatení produktu kupujúcim sú možné nasledujúce situácie (stavy):

• Tovar odovzdajte kupujúcemu, zmena nie je potrebná.
• Dajte kupujúcemu tovar a zmeňte ho.
• Kupujúci nedostane tovar z dôvodu nedostatku peňazí.
• Kupujúci neprevezme tovar z dôvodu jeho neprítomnosti.

Použitie štátneho vzoru

• Definujte existujúcu alebo vytvorte novú triedu Context wrapper, ktorú bude klient používať ako „stavový stroj“.
• Vytvorte základnú triedu State, ktorá replikuje rozhranie triedy Context. Každá metóda má jeden dodatočný parameter: inštanciu triedy Context. Trieda State môže definovať akékoľvek užitočné „predvolené“ správanie.
• Vytvorte triedy odvodené od štátu pre všetky možné stavy.
• Trieda Context wrapper má odkaz na objekt aktuálneho stavu.
• Trieda Context jednoducho deleguje všetky požiadavky prijaté od klienta na objekt „aktuálny stav“, pričom adresa objektu Context sa odovzdá ako ďalší parameter.
• Pomocou tejto adresy môžu metódy triedy State v prípade potreby zmeniť "aktuálny stav" triedy Context.

Vlastnosti štátneho vzoru

• Štátne objekty sú často jednotlivé.
• Flyweight ukazuje, ako a kedy je možné objekty štátu rozdeliť.
• Vzor Interpreter môže použiť stav na definovanie kontextov analýzy.
• Vzory State a Bridge majú podobné štruktúry, s výnimkou toho, že Bridge umožňuje hierarchiu tried obalov (analógy tried „obalov“), zatiaľ čo State nie. Tieto vzory majú podobnú štruktúru, ale riešia rôzne problémy: Stav umožňuje objektu meniť svoje správanie v závislosti od jeho vnútorného stavu, zatiaľ čo Bridge oddeľuje abstrakciu od jej implementácie, aby sa dali meniť nezávisle od seba.
• Implementácia vzoru štátu je založená na vzore Stratégia. Rozdiely spočívajú v ich účele.

Implementácia štátneho vzoru

Uvažujme príklad konečného automatu s dvoma možnými stavmi a dvoma udalosťami.

#include pomocou menného priestoru std; class Machine ( class State *current; public: Machine(); void setCurrent(State *s) ( current = s; ) void on(); void off(); ); class State ( public: virtual void on(Machine *m) ( cout<< " already ON\n"; } virtual void off(Machine *m) { cout << " already OFF\n"; } }; void Machine::on() { current->Na toto); ) void Machine::off() ( current->off(this); ) class ON: public State ( public: ON() ( cout<< " ON-ctor "; }; ~ON() { cout << " dtor-ON\n"; }; void off(Machine *m); }; class OFF: public State { public: OFF() { cout << " OFF-ctor "; }; ~OFF() { cout << " dtor-OFF\n"; }; void on(Machine *m) { cout << " going from OFF to ON"; m->setCurrent(new ON()); vymazať toto; )); void ON::off (Stroj *m) ( cout<< " going from ON to OFF"; m->setCurrent(new OFF()); vymazať toto; ) Machine::Machine() ( aktuálny = nový OFF(); cout<< "\n"; } int main() { void(Machine:: *ptrs)() = { Machine::off, Machine::on }; Machine fsm; int num; while (1) { cout << "Enter 0/1: "; cin >>num; (fsm. *ptrs)(); ))

15.02.2016
21:30

Vzor Stav je určený na navrhovanie tried, ktoré majú viacero nezávislých logických stavov. Poďme rovno na príklad.

Povedzme, že vyvíjame triedu ovládania webovej kamery. Kamera môže byť v troch stavoch:

1. Neinicializované. Nazvime to NotConnectedState ;
2. Inicializované a pripravené na použitie, ale zatiaľ sa nezachytávajú žiadne snímky. Nech je to ReadyState ;
3. Aktívny režim snímania snímok. Označme ActiveState .

Keďže pracujeme so stavovým vzorom, je najlepšie začať s obrázkom stavového diagramu:

Teraz premeňme tento diagram na kód. Aby sme implementáciu nekomplikovali, vynechávame kód pre prácu s webovými kamerami. V prípade potreby môžete sami pridať príslušné volania funkcií knižnice.

Okamžite poskytnem celý zoznam s minimálnymi komentármi. Ďalej budeme podrobnejšie diskutovať o kľúčových detailoch tejto implementácie.

#include #define DECLARE_GET_INSTANCE(ClassName) \ static ClassName* getInstance() (\ static ClassName instance;\ return \ ) class WebCamera ( public: typedef std::string Frame; public: // *********** ******************************************** // Výnimky // ****** ************************************************* trieda Nepodporované: verejná std: :exception ( ); public: // ************************************************* ******** ********* // Štáty // ********************************** ******** ************** class NotConnectedState; class ReadyState; class ActiveState; class State ( public: virtual ~State() ( ) virtual void connect(WebCamera*) ( throw NotSupported(); ) virtuálne neplatné odpojenie (WebCamera* cam) ( std::cout<< "Деинициализируем камеру..." << std::endl; // ... cam->changeState(NotConnectedState::getInstance()); ) virtual void start(WebCamera*) ( throw NotSupported(); ) virtual void stop(WebCamera*) ( throw NotSupported(); ) virtual Frame getFrame(WebCamera*) ( throw NotSupported(); ) protected: State() ( ) ); // ********************************************************** ** trieda NotConnectedState: public State ( public: DECLARE_GET_INSTANCE(NotConnectedState) void connect(WebCamera* cam) ( std::cout<< "Инициализируем камеру..." << std::endl; // ... cam->changeState(ReadyState::getInstance()); ) void unlock(WebCamera*) ( throw NotSupported(); ) private: NotConnectedState() ( ) ); // ********************************************************** ** trieda ReadyState: public State ( public: DECLARE_GET_INSTANCE(ReadyState) void start(WebCamera* cam) ( std::cout<< "Запускаем видео-поток..." << std::endl; // ... cam->changeState(ActiveState::getInstance()); ) private: ReadyState() ( ) ); // ********************************************************** ** trieda ActiveState: public State ( public: DECLARE_GET_INSTANCE(ActiveState) void stop (WebCamera* cam) ( std::cout<< "Останавливаем видео-поток..." << std::endl; // ... cam-> << "Получаем текущий кадр..." << std::endl; // ... return "Current frame"; } private: ActiveState() { } }; public: explicit WebCamera(int camID) : m_camID(camID), m_state(NotConnectedState::getInstance()) { } ~WebCamera() { try { disconnect(); } catch(const NotSupported& e) { // Обрабатываем исключение } catch(...) { // Обрабатываем исключение } } void connect() { m_state->pripojiť (toto); ) void unlock() ( m_state->disconnect(to); ) void start() ( m_state->start(to); ) void stop() ( m_state->stop(this); ) Frame getFrame() ( return m_state ->getFrame(this); ) private: void changeState(State* newState) ( m_state = newState; ) private: int m_camID; State* m_state; );

Upozorňujem na makro DECLARE_GET_INSTANCE. Samozrejme, používanie makier v C++ sa neodporúča. To sa však týka prípadov, keď makro funguje ako analóg funkcie šablóny. V tomto prípade vždy uprednostňujte to druhé.

V našom prípade je makro určené na definovanie statickej funkcie potrebnej na implementáciu . Preto možno jeho použitie považovať za opodstatnené. Koniec koncov, umožňuje znížiť duplicitu kódu a nepredstavuje žiadne vážne hrozby.

Triedy State deklarujeme v hlavnej triede – WebCamera. Pre stručnosť som použil inline definície členských funkcií všetkých tried. V skutočných aplikáciách je však lepšie riadiť sa odporúčaniami o oddelení deklarácie a implementácie do súborov h a cpp.

Stavové triedy sú deklarované vo WebCamera, takže majú prístup k súkromným poliam tejto triedy. To samozrejme vytvára mimoriadne tesné spojenie medzi všetkými týmito triedami. Ukázalo sa však, že štáty sú také špecifické, že ich opätovné použitie v iných kontextoch neprichádza do úvahy.

Základom hierarchie stavových tried je abstraktná trieda WebCamera::State:

Stav triedy ( public: virtual ~State() ( ) virtual void connect(WebCamera*) ( throw NotSupported(); ) virtual void cancel(WebCamera* cam) ( std::cout<< "Деинициализируем камеру..." << std::endl; // ... cam->changeState(NotConnectedState::getInstance()); ) virtual void start(WebCamera*) ( throw NotSupported(); ) Virtual Void stop(WebCamera*) ( throw NotSupported(); ) virtual Frame getFrame(WebCamera*) ( throw NotSupported(); ) protected: State() ( ) );

Všetky jej členské funkcie zodpovedajú funkciám samotnej triedy WebCamera. Priame delegovanie prebieha:

Trieda WebCamera ( // ... void connect() ( m_state->connect(this); ) void unlock() ( m_state->disconnect(this); ) void start() ( m_state->start(this); ) void stop() ( m_state->stop(this); ) Frame getFrame() ( return m_state->getFrame(this); ) // ... State* m_state; )

Kľúčovou vlastnosťou je, že objekt State akceptuje ukazovateľ na inštanciu WebCamera, ktorá ho volá. To vám umožňuje mať iba tri štátne objekty pre ľubovoľne veľký počet kamier. Táto možnosť je dosiahnutá použitím vzoru Singleton. Samozrejme, v kontexte príkladu z toho nezískate významný zisk. Ale poznať túto techniku ​​je stále užitočné.

Sama o sebe trieda WebCamera nerobí prakticky nič. Je úplne závislý od svojich Štátov. A tieto štáty zase určujú podmienky vykonávania operácií a poskytujú potrebné súvislosti.

Väčšina členských funkcií WebCamera::State používa našu vlastnú WebCamera::NotSupported . Toto je úplne vhodné predvolené správanie. Ak sa napríklad niekto pokúsi inicializovať kameru, keď už bola inicializovaná, celkom prirodzene dostane výnimku.

Zároveň poskytujeme predvolenú implementáciu pre WebCamera::State::disconnect(). Toto správanie je vhodné pre dva z troch stavov. V dôsledku toho predchádzame duplicite kódu.

Ak chcete zmeniť stav, použite súkromnú členskú funkciu WebCamera::changeState() :

Void changeState(State* newState) ( m_state = newState; )

Teraz k implementácii konkrétnych štátov. Pre WebCamera::NotConnectedState stačí prepísať operácie connect() a odpojenie():

Trieda NotConnectedState: public State ( public: DECLARE_GET_INSTANCE(NotConnectedState) void connect(WebCamera* cam) ( std::cout<< "Инициализируем камеру..." << std::endl; // ... cam->changeState(ReadyState::getInstance()); ) void unlock(WebCamera*) ( throw NotSupported(); ) private: NotConnectedState() ( ) );

Pre každý štát môžete vytvoriť jednu inštanciu. To nám zaručuje vyhlásenie súkromného konštruktéra.

Ďalším dôležitým prvkom prezentovanej implementácie je, že do nového štátu sa presťahujeme len v prípade úspechu. Ak napríklad dôjde k zlyhaniu počas inicializácie kamery, je príliš skoro na to, aby ste vstúpili do stavu ReadyState. Hlavnou myšlienkou je úplná zhoda medzi skutočným stavom kamery (v našom prípade) a objektu State.

Fotoaparát je teda pripravený. Vytvorme zodpovedajúcu triedu WebCamera::ReadyState State:

Trieda ReadyState: verejný stav ( public: DECLARE_GET_INSTANCE(ReadyState) void start (WebCamera* cam) ( std::cout<< "Запускаем видео-поток..." << std::endl; // ... cam->changeState(ActiveState::getInstance()); ) private: ReadyState() ( ) );

Z Ready State môžeme vstúpiť do aktívneho Frame Capture State. Na tento účel je poskytnutá operácia start(), ktorú sme implementovali.

Nakoniec sme dosiahli posledný logický stav kamery, WebCamera::ActiveState:

Trieda ActiveState: public State ( public: DECLARE_GET_INSTANCE(ActiveState) void stop (WebCamera* cam) ( std::cout<< "Останавливаем видео-поток..." << std::endl; // ... cam->changeState(ReadyState::getInstance()); ) Frame getFrame(WebCamera*) ( std::cout<< "Получаем текущий кадр..." << std::endl; // ... return "Current frame"; } private: ActiveState() { } };

V tomto stave môžete zastaviť zachytávanie snímok pomocou stop() . V dôsledku toho sa vrátime späť do WebCamera::ReadyState. Okrem toho môžeme prijímať snímky, ktoré sa hromadia vo vyrovnávacej pamäti fotoaparátu. Pre jednoduchosť „rámčekom“ rozumieme obyčajný reťazec. V skutočnosti to bude nejaký druh bajtového poľa.

Teraz si môžeme zapísať typický príklad práce s našou triedou WebCamera:

Int main() ( WebCamera cam(0); try ( // kamera v NotConnectedState cam.connect(); // kamera v ReadyState cam.start(); // kamera v ActiveState std::cout<< cam.getFrame() << std::endl; cam.stop(); // Можно было сразу вызвать disconnect() // cam в Состоянии ReadyState cam.disconnect(); // cam в Состоянии NotConnectedState } catch(const WebCamera::NotSupported& e) { // Обрабатываем исключение } catch(...) { // Обрабатываем исключение } return 0; }

Výsledkom bude výstup do konzoly:

Inicializovať kameru... Spustiť tok videa... Získať aktuálnu snímku... Aktuálna snímka Zastaviť tok videa... Deinicializovať kameru...

Teraz skúsme vyprovokovať chybu. Zavolajme connect() dvakrát za sebou:

Int main() ( WebCamera cam(0); try ( // kamera v NotConnectedState cam.connect(); // cam v ReadyState // Ale pre tento stav nie je k dispozícii operácia connect()! cam.connect( ); // Vyvolá výnimku NotSupported ) catch(const WebCamera::NotSupported& e) ( std::cout<< "Произошло исключение!!!" << std::endl; // ... } catch(...) { // Обрабатываем исключение } return 0; }

Tu je to, čo z toho vyplýva:

Inicializuje sa fotoaparát... Nastala výnimka!!! Poďme deinicializovať fotoaparát...

Upozorňujeme, že fotoaparát bol stále deinicializovaný. V deštruktore webovej kamery sa vyskytlo volanie unlock(). Tie. vnútorný stav objektu zostáva absolútne správny.

závery

Pomocou vzoru Stav môžete jedinečne transformovať stavový diagram na kód. Na prvý pohľad sa implementácia ukázala ako podrobná. Dospeli sme však k jasnému rozdeleniu do možných kontextov pre prácu s hlavnou triedou WebCamera. Výsledkom bolo, že pri písaní každého jednotlivého štátu sme sa mohli sústrediť na úzku úlohu. A toto je najlepší spôsob, ako napísať jasný, zrozumiteľný a spoľahlivý kód.