Państwo. Klasy stanów dla każdego stanu

Oczywiście nie jest to jedyny sposób na wdrożenie hierarchii. Jeśli jednak nie użyjesz szablonu Gang Czterech Państw, nie zadziała. Zamiast tego możesz modelować przejrzystą hierarchię bieżących stanów i superstanów za pomocą stos stany zamiast pojedynczego stanu w klasie głównej.

Bieżący stan będzie na górze stosu, poniżej będzie jego superstan, a następnie superstan Ten superpaństwa itp. A kiedy musisz zaimplementować zachowanie specyficzne dla stanu, zaczynasz od szczytu stosu i schodzisz w dół, aż stan sobie z tym poradzi. (A jeśli tego nie przetworzy, po prostu to zignorujesz).

Automat z pamięcią magazynka

Istnieje inne popularne rozszerzenie maszyn stanowych, które również korzysta ze stosu stanu. Tylko tutaj stos reprezentuje zupełnie inną koncepcję i służy do rozwiązywania różnych problemów.

Problem polega na tym, że maszyna stanów nie ma koncepcji historie. Czy wiesz w jakim jesteś stanie? jesteś, ale nie masz informacji o tym, w jakim stanie się znajdujesz był. W związku z tym nie ma łatwego sposobu na powrót do poprzedniego stanu.

Oto prosty przykład: wcześniej pozwalaliśmy naszej nieustraszonej bohaterce uzbroić się po zęby. Kiedy strzela z broni, potrzebujemy nowego stanu, aby odtwarzać animację strzału, pojawiać się pocisk i towarzyszące mu efekty wizualne. W tym celu tworzymy nowy FiringState i dokonujemy do niego przejść ze wszystkich stanów, w których bohaterka może strzelać wciskając przycisk strzału.

Ponieważ to zachowanie jest powielane w wielu stanach, w tym miejscu można użyć hierarchicznej maszyny stanów do ponownego użycia kodu.

Trudność polega na tym, że musisz w jakiś sposób zrozumieć, do jakiego stanu musisz przejść. Po strzelanie. Bohaterka może wystrzelić cały magazynek stojąc w miejscu, biegając, skacząc czy kucając. Po zakończeniu sekwencji strzelań musi powrócić do stanu, w jakim znajdowała się przed oddaniem strzału.

Jeśli przywiążemy się do czystego FSM, natychmiast zapominamy, w jakim stanie się znajdowaliśmy. Aby to śledzić, musimy zdefiniować wiele niemal identycznych stanów - strzelanie z pozycji stojącej, strzelanie z biegu, strzelanie z wyskoku itp. W ten sposób mamy zakodowane na stałe przejścia, które po zakończeniu przechodzą do prawidłowego stanu.

Tak naprawdę potrzebujemy możliwości zapamiętania stanu, w jakim byliśmy przed strzelaniną i zapamiętania go ponownie po strzelaninie. Tutaj znowu może nam pomóc teoria automatów. Odpowiednia struktura danych nazywa się Automatem Pushdown.

Tam, gdzie w automacie skończonym mamy pojedynczy wskaźnik do stanu, w automacie ze skończoną pamięcią jest ich stos. W FSM przejście do nowego stanu zastępuje poprzedni. Maszyna z pamięcią magazynkową również pozwala to zrobić, ale dodaje jeszcze dwie operacje:

Możesz miejsce (naciskać) nowy stan na stosie. Bieżący stan zawsze będzie na górze stosu, jest to więc operacja przejścia do nowego stanu. Ale jednocześnie stary stan pozostaje bezpośrednio pod obecnym na stosie i nie znika bez śladu.

Możesz wyciąg (Muzyka pop) najwyższy stan ze stosu. Stan znika, a to, co było pod nim, staje się aktualne.

To wszystko, czego potrzebujemy do strzelania. Tworzymy Jedyną rzeczą stan strzelania. Kiedy naciśniemy przycisk wyzwalania w innym stanie, nastąpi to miejsce (naciskać) stan strzelania stosem. Kiedy animacja strzelania się zakończy, my wyciąg (Muzyka pop) stan i maszyna z pamięcią magazynka automatycznie przywraca nas do poprzedniego stanu.

Jak bardzo są one naprawdę przydatne?

Nawet przy tej ekspansji maszyn stanowych ich możliwości są nadal dość ograniczone. W dzisiejszej AI dominuje trend polegający na używaniu takich rzeczy jak drzewa zachowań(drzewa zachowań) i systemy planowania(systemy planowania). A jeśli szczególnie interesuje Cię dziedzina sztucznej inteligencji, cały ten rozdział powinien zaostrzyć Twój apetyt. Aby go zadowolić, będziesz musiał sięgnąć do innych książek.

Nie oznacza to wcale, że maszyny o skończonych stanach, maszyny z pamięcią magazynową i inne podobne systemy są całkowicie bezużyteczne. W niektórych przypadkach są to dobre narzędzia do modelowania. Maszyny stanowe są przydatne, gdy:

• Masz jednostkę, której zachowanie zmienia się w zależności od jej stanu wewnętrznego.
• Warunek ten jest ściśle podzielony na stosunkowo niewielką liczbę konkretnych opcji.
• Jednostka stale reaguje na serię poleceń wejściowych lub zdarzeń.

W grach maszyny stanowe są zwykle używane do modelowania sztucznej inteligencji, ale można ich również używać do implementowania danych wprowadzanych przez użytkownika, nawigacji w menu, analizowania tekstu, protokołów sieciowych i innych zachowań asynchronicznych.

Stan to wzorzec zachowania obiektu, który określa różną funkcjonalność w zależności od wewnętrznego stanu obiektu. witryna internetowa źródło witryny internetowej oryginał

Warunki, zadanie, cel

Motywacja

Główną ideą tego wzorca jest wprowadzenie klasy abstrakcyjnej Stan TCP do reprezentowania różnych stanów połączenia. Ta klasa deklaruje interfejs wspólny dla wszystkich klas opisujących różnych procesów roboczych. oryginalne źródło.ru

stan : schorzenie. W tych podklasach Stan TCP Zaimplementowane jest zachowanie specyficzne dla stanu. Na przykład na zajęciach TCPUstalono I TCPZamknięte zaimplementowano zachowanie specyficzne dla stanu Przyjęty I Zamknięte odpowiednio. oryginalne źródło witryny internetowej

oryginał.ru

Klasa Połączenie TCP przechowuje obiekt stanu (instancję podklasy Stan TCP) reprezentujący bieżący stan połączenia i deleguje wszystkie żądania zależne od stanu do tego obiektu. Połączenie TCP używa własnej instancji podklasy Stan TCP całkiem proste: wywoływanie metod pojedynczego interfejsu Stan TCP, tylko w zależności od tego, jaka konkretna podklasa jest aktualnie przechowywana Stan TCP-a - wynik jest inny, tj. w rzeczywistości wykonywane są operacje specyficzne tylko dla tego stanu połączenia. źródło: Original.ru

I za każdym razem, gdy zmienia się stan połączeniaPołączenie TCP zmienia swój obiekt stanu. Na przykład, gdy nawiązane połączenie zostanie zamknięte, Połączenie TCP zastępuje instancję klasy TCPUstalono Kopiuj TCPZamknięte. oryginalna witryna źródłowa

Znaki zastosowania, użycie wzorca Stan

1. Kiedy zachowanie obiektu zależy od jego stanu i musi się zmienić w czasie wykonywania. źródło oryginał.ru
2. Gdy kod operacji zawiera instrukcje warunkowe składające się z wielu gałęzi, w których wybór gałęzi zależy od stanu. Zwykle w tym przypadku stan jest reprezentowany przez wyliczone stałe. Często ta sama struktura instrukcji warunkowej powtarza się w kilku operacjach.Wzorzec stanu sugeruje umieszczenie każdej gałęzi w osobnej klasie. Pozwala to traktować stan obiektu jako niezależny obiekt, który może zmieniać się niezależnie od innych. źródło witryny oryginalna witryna

Rozwiązanie

źródło.ru

Uczestnicy wzorca Państwa

1. Kontekst(Połączenie TCP) - kontekst.
   Definiuje pojedynczy interfejs dla klientów.
   Przechowuje instancję podklasy Stan betonu, który określa aktualny stan. zajęcia z kodowania
2. Państwo(TCPState) - stan.
   Definiuje interfejs do hermetyzacji zachowania związanego z określonym stanem kontekstu. źródło witryny oryginał witryny
3. Podklasy Stan betonu(TCPEstablished, TCPListen, TCPClosed) - konkretny stan.
   Każda podklasa implementuje zachowanie powiązane z pewnym stanem kontekstu Kontekst. oryginalna witryna źródłowa

Schemat wykorzystania wzorca State

Kontekst może przekazać sam siebie jako argument do obiektu Państwo, który przetworzy żądanie. Dzięki temu obiekt stanu ( Stan betonu) w razie potrzeby uzyskaj dostęp do kontekstu. zajęcia z kodowania

Kontekst- To jest główny interfejs dla klientów. Klienci mogą konfigurować kontekst za pomocą obiektów stanu Państwo(dokładniej Stan betonu). Po skonfigurowaniu kontekstu klienci nie muszą już komunikować się bezpośrednio z obiektami stanu (tylko za pośrednictwem wspólnego interfejsu Państwo). źródło.ru

W tym przypadku też Kontekst lub same podklasy Stan betonu może decydować, pod jakimi warunkami i w jakiej kolejności następuje zmiana stanów. witryna internetowa źródło witryny internetowej oryginał

Pytania dotyczące implementacji wzorca Państwa

1. Co decyduje o przejściach pomiędzy stanami.
   Wzorzec stanu nie mówi nic o tym, który uczestnik określa warunki (kryteria) przejścia między stanami. Jeśli kryteria są stałe, można je wdrożyć bezpośrednio w klasie Kontekst. Jednak ogólnie rzecz biorąc, bardziej elastycznym i poprawnym podejściem jest zezwolenie na podklasy samych klas Państwo określić kolejny stan i moment przejścia. Aby to zrobić na zajęciach Kontekst musimy dodać interfejs, który pozwala na korzystanie z obiektów Państwo ustawić jego stan.
   Tę zdecentralizowaną logikę przejścia można łatwiej modyfikować i rozszerzać — wystarczy zdefiniować nowe podklasy Państwo. Wadą decentralizacji jest to, że każda podklasa Państwo musi „wiedzieć” o przynajmniej jednej podklasie innego stanu (do której faktycznie może przełączyć stan bieżący), co wprowadza zależności implementacyjne pomiędzy podklasami. źródło witryny oryginał witryny

   źródło oryginał.ru

2. Alternatywa tabelaryczna.
   Istnieje inny sposób konstruowania kodu sterowanego stanem. Jest to zasada skończonej maszyny stanów. Wykorzystuje tabelę do mapowania wejść na przejścia stanów. Za jego pomocą można określić, w jaki stan należy przejść po nadejściu określonych danych wejściowych. Zasadniczo zastępujemy kod warunkowy wyszukiwaniem w tabeli.
   Główną zaletą maszyny jest jej regularność: aby zmienić kryteria przejścia, wystarczy zmodyfikować tylko dane, a nie kod. Ale są też wady:
   - przeszukiwanie tabeli jest często mniej efektywne niż wywołanie funkcji,
   - przedstawienie logiki przejścia w jednolitej formie tabelarycznej sprawia, że ​​kryteria są mniej jednoznaczne i przez to trudniejsze do zrozumienia,
   - zwykle trudno jest dodać akcje towarzyszące przejściom pomiędzy stanami. Metoda tabelaryczna uwzględnia stany i przejścia między nimi, wymaga jednak uzupełnienia, aby przy każdej zmianie stanu można było dokonywać dowolnych obliczeń.
   Główną różnicę między maszynami stanów opartymi na tabelach a stanem wzorca można sformułować w następujący sposób: Stan wzorca modeluje zachowanie zależne od stanu, a metoda tabelaryczna skupia się na definiowaniu przejść między stanami. oryginał.ru

   oryginalna witryna źródłowa

3. Tworzenie i niszczenie obiektów stanu.
   Podczas procesu programowania zwykle musisz wybierać pomiędzy:
   - tworzenie obiektów stanu wtedy, gdy są potrzebne i niszczenie ich bezpośrednio po użyciu,
   - tworząc je z góry i na zawsze.

   Pierwsza opcja jest preferowana, gdy nie wiadomo z góry, w jakie stany wpadnie system, a kontekst zmienia stan stosunkowo rzadko. Jednocześnie nie tworzymy obiektów, które nigdy nie zostaną wykorzystane, co jest ważne, jeśli w obiektach stanu przechowywanych jest dużo informacji. Kiedy zmiany stanu występują często i nie chcesz niszczyć reprezentujących je obiektów (ponieważ mogą wkrótce być ponownie potrzebne), powinieneś zastosować drugie podejście. Czas na tworzenie obiektów poświęcany jest tylko raz, na samym początku, a czasu na niszczenie nie poświęca się w ogóle. Co prawda takie podejście może okazać się niewygodne, gdyż w kontekście muszą znajdować się odniesienia do wszystkich stanów, w jakie teoretycznie mógłby wpaść system. źródło oryginał.ru

   oryginał.ru źródło

4. Korzystanie z dynamicznej zmiany.
   Możliwe jest różnicowanie zachowania na żądanie poprzez zmianę klasy obiektu w czasie wykonywania, ale większość języków obiektowych tego nie obsługuje. Wyjątkiem jest Perl, JavaScript i inne języki oparte na silnikach skryptowych, które zapewniają taki mechanizm i dlatego bezpośrednio obsługują Pattern State. Dzięki temu obiekty mogą zmieniać swoje zachowanie poprzez zmianę kodu klasy. źródło.ru

   .ru źródło oryginalne

wyniki

1. Lokalizuje zachowanie zależne od stanu.
   I dzieli go na części odpowiadające stanom. Wzorzec stanu umieszcza całe zachowanie związane z określonym stanem w oddzielnym obiekcie. Ponieważ kod zależny od stanu jest w całości zawarty w jednej z podklas klasy Państwo, możesz dodać nowe stany i przejścia, po prostu tworząc nowe podklasy.
   Zamiast tego można użyć elementów danych do zdefiniowania stanów wewnętrznych, a następnie operacji obiektu Kontekst sprawdzi te dane. Jednak w tym przypadku podobne instrukcje warunkowe lub instrukcje rozgałęziające byłyby rozproszone po całym kodzie klasy Kontekst. Jednakże dodanie nowego stanu wymagałoby zmiany kilku operacji, co utrudniłoby konserwację. Wzorzec stanu rozwiązuje ten problem, ale tworzy także inny, ponieważ zachowanie dla różnych stanów zostaje rozłożone na kilka podklas Państwo. Zwiększa to liczbę zajęć. Oczywiście jedna klasa jest bardziej zwarta, ale jeśli jest wiele stanów, to taki rozkład jest bardziej efektywny, gdyż w przeciwnym razie trzeba by mieć do czynienia z uciążliwymi instrukcjami warunkowymi.
   Posiadanie uciążliwych instrukcji warunkowych jest niepożądane, podobnie jak długie procedury. Są zbyt monolityczne, dlatego modyfikowanie i rozszerzanie kodu staje się problemem. Wzorzec stanu oferuje lepszy sposób konstruowania kodu zależnego od stanu. Logika opisująca przejścia stanów nie jest już opakowana w monolityczne stwierdzenia Jeśli Lub przełącznik, ale rozdzielone pomiędzy podklasami Państwo. Hermetyzując każde przejście i akcję w klasę, stan staje się pełnoprawnym obiektem. Poprawia to strukturę kodu i czyni jego cel jaśniejszym. oryginał.ru
2. Sprawia, że ​​przejścia między stanami są wyraźne.
   Jeśli obiekt definiuje swój aktualny stan wyłącznie w oparciu o dane wewnętrzne, to przejścia pomiędzy stanami nie mają wyraźnej reprezentacji; pojawiają się one jedynie jako przypisania do określonych zmiennych. Wprowadzenie oddzielnych obiektów dla różnych stanów sprawia, że ​​przejścia są bardziej wyraźne. Poza tym obiekty Państwo może chronić kontekst Kontekst z niedopasowania zmiennych wewnętrznych, ponieważ przejścia z punktu widzenia kontekstu są działaniami atomowymi. Aby dokonać przejścia należy zmienić wartość tylko jednej zmiennej (zmiennej obiektowej Państwo w klasie Kontekst), a nie kilka. źródło.ru
3. Obiekty stanu można udostępniać.
   Jeśli w obiekcie stanu Państwo nie ma zmiennych instancji, co oznacza, że ​​stan, który reprezentuje, jest kodowany wyłącznie przez sam typ, wówczas różne konteksty mogą współużytkować ten sam obiekt Państwo. Kiedy państwa są rozdzielone w ten sposób, są one zasadniczo oportunistami (patrz wzór oportunistyczny), którzy nie mają stanu wewnętrznego, a jedynie zachowanie. źródło witryny oryginalna witryna

Przykład

Na początek zdefiniujmy klasę Połączenie TCP, który zapewnia interfejs do przesyłania danych i obsługuje żądania zmiany stanu: TCPConnection. oryginał.ru źródło

W zmiennej składowej państwo klasa Połączenie TCP przechowywana jest instancja klasy Stan TCP. Ta klasa powiela interfejs zmiany stanu zdefiniowany w klasie Połączenie TCP. źródło: Original.ru

oryginalna witryna źródłowa

Połączenie TCP deleguje wszystkie żądania zależne od stanu do instancji przechowywanej w stanie Stan TCP. Również na zajęciach Połączenie TCP jest operacja Zmień stan, za pomocą którego możesz zapisać w tej zmiennej wskaźnik do innego obiektu Stan TCP. Konstruktor klasy Połączenie TCP inicjuje państwo wskaźnik do stanu zamkniętego TCPZamknięte(zdefiniujemy to poniżej). źródło oryginał.ru

oryginał.ru źródło

Każda operacja Stan TCP akceptuje instancję Połączenie TCP jako parametr, umożliwiając w ten sposób obiekt Stan TCP dostęp do danych obiektu Połączenie TCP i zmień stan połączenia. .ru

W klasie Stan TCP zaimplementowano domyślne zachowanie dla wszystkich delegowanych do niego żądań. Może także zmienić stan obiektu Połączenie TCP poprzez operację Zmień stan. Stan TCP znajduje się w tym samym pakiecie co Połączenie TCP, więc ma również dostęp do tej operacji: TCPState . oryginalna witryna źródłowa

oryginał.ru

W podklasach Stan TCP Zaimplementowano zachowanie zależne od stanu. Połączenie TCP może znajdować się w wielu stanach: Przyjęty(zainstalowany), Słuchający(słuchający), Zamknięte(zamknięte) itp., a każda z nich ma swoją własną podklasę Stan TCP. Dla uproszczenia rozważymy szczegółowo tylko 3 podklasy - TCPUstalono, TCPSłuchaj I TCPZamknięte. oryginalne źródło witryny internetowej

Źródło Ru

W podklasach Stan TCP implementuje zachowanie zależne od stanu dla tych żądań, które są ważne w tym stanie. .ru

oryginalna witryna źródłowa

Po wykonaniu działań specyficznych dla stanu, te operacje źródło oryginał.ru

przyczyna Zmień stan zmienić stan obiektu Połączenie TCP. On sam nie ma żadnych informacji na temat protokołu TCP. To podklasy Stan TCP zdefiniować przejścia pomiędzy stanami i działaniami podyktowanymi protokołem. oryginał.ru

źródło oryginał.ru

Znane zastosowania wzorca stanu

Aby odzwierciedlić zależność zachowania edytora od bieżącego narzędzia, można skorzystać ze wzorca stanu. oryginalne źródło.ru

Można zdefiniować klasę abstrakcyjną Narzędzie, których podklasy implementują zachowanie specyficzne dla narzędzia. Edytor graficzny przechowuje łącze do bieżącego obiektu Zbytl i przekazuje mu przychodzące żądania. Po wybraniu narzędzia edytor używa innego obiektu, co powoduje zmianę zachowania. .ru

Technikę tę wykorzystuje się w ramach edytorów graficznych HotDraw i Unidraw. Umożliwia klientom łatwe definiowanie nowych typów narzędzi. W HotDraw Klasa Kontroler rysunków przekazuje żądania do bieżącego obiektu Narzędzie. W Unidraw nazywane są odpowiednie klasy Widz I Narzędzie. Poniższy diagram klas przedstawia schematyczną reprezentację interfejsów klas Narzędzie

Cel wzorca Stan

• Wzorzec State pozwala obiektowi zmienić swoje zachowanie w zależności od jego stanu wewnętrznego. Wygląda na to, że obiekt zmienił klasę.
• Wzorzec stanu jest zorientowaną obiektowo implementacją maszyny stanu.

Problem do rozwiązania

Zachowanie obiektu zależy od jego stanu i musi się zmieniać w trakcie wykonywania programu. Taki schemat można zrealizować wykorzystując wiele operatorów warunkowych: na podstawie analizy aktualnego stanu obiektu podejmowane są określone działania. Jednak przy dużej liczbie stanów instrukcje warunkowe będą rozproszone po całym kodzie i taki program będzie trudny w utrzymaniu.

Omówienie wzorca Państwa

Wzorzec State rozwiązuje ten problem w następujący sposób:

• Wprowadza klasę Context, która definiuje interfejs do świata zewnętrznego.
• Wprowadza abstrakcyjną klasę State.
• Reprezentuje różne „stany” maszyny stanowej jako podklasy stanu.
• Klasa Context posiada wskaźnik do bieżącego stanu, który zmienia się wraz ze zmianą stanu maszyny stanowej.

Wzorzec Stan nie definiuje, gdzie dokładnie jest określany warunek przejścia do nowego stanu. Istnieją dwie opcje: klasa Kontekst lub podklasy Stan. Zaletą tej drugiej opcji jest to, że można łatwo dodawać nowe klasy pochodne. Wadą jest to, że każda podklasa stanu musi wiedzieć o swoich sąsiadach, aby dokonać przejścia do nowego stanu, co wprowadza zależności pomiędzy podklasami.

Istnieje również alternatywne podejście do projektowania maszyn o skończonych stanach, oparte na tabelach, polegające na wykorzystaniu tabeli, która w unikalny sposób odwzorowuje dane wejściowe na przejścia między stanami. Jednak takie podejście ma wady: trudno jest dodać wykonanie akcji podczas wykonywania przejść. Podejście oparte na wzorcu stanu wykorzystuje kod (zamiast struktur danych) do wykonywania przejść między stanami, dzięki czemu te akcje można łatwo dodać.

Struktura wzorca stanu

Klasa Context definiuje zewnętrzny interfejs dla klientów i przechowuje odwołanie do bieżącego stanu obiektu State. Interfejs abstrakcyjnej klasy bazowej State jest taki sam jak interfejs Context z wyjątkiem jednego dodatkowego parametru – wskaźnika do instancji Context. Klasy pochodne stanu definiują zachowanie specyficzne dla stanu. Klasa opakowania Context deleguje wszystkie odebrane żądania do obiektu „bieżącego stanu”, który może użyć otrzymanego dodatkowego parametru w celu uzyskania dostępu do instancji Context.

Wzorzec State pozwala obiektowi zmienić swoje zachowanie w zależności od jego stanu wewnętrznego. Podobny obraz można zaobserwować w działaniu automatu. Maszyny mogą mieć różne stany w zależności od dostępności towaru, ilości otrzymanych monet, możliwości wymiany pieniędzy itp. Po dokonaniu przez kupującego wyboru i opłaceniu produktu możliwe są następujące sytuacje (stany):

• Oddaj towar kupującemu, zmiana nie jest wymagana.
• Daj kupującemu towar i zmień.
• Kupujący nie otrzyma towaru ze względu na brak wystarczających środków pieniężnych.
• Kupujący nie otrzyma towaru z powodu jego braku.

Korzystanie ze wzorca stanu

• Zdefiniuj istniejącą lub utwórz nową klasę opakowania kontekstowego, która będzie używana przez klienta jako „maszyna stanu”.
• Utwórz podstawową klasę State, która replikuje interfejs klasy Context. Każda metoda przyjmuje jeden dodatkowy parametr: instancję klasy Context. Klasa State może definiować dowolne przydatne zachowanie „domyślne”.
• Utwórz klasy wywodzące się ze stanu dla wszystkich możliwych stanów.
• Klasa opakowania Context zawiera odwołanie do obiektu bieżącego stanu.
• Klasa Context po prostu deleguje wszystkie żądania otrzymane od klienta do obiektu „bieżącego stanu”, przekazując adres obiektu Context jako dodatkowy parametr.
• Korzystając z tego adresu, metody klasy State mogą w razie potrzeby zmienić „bieżący stan” klasy Context.

Cechy wzorca Stan

• Obiekty stanu są często singletonami.
• Flyweight pokazuje, jak i kiedy można dzielić obiekty State.
• Wzorzec interpretera może używać stanu do definiowania kontekstów analizowania.
• Wzorce State i Bridge mają podobne struktury, z tą różnicą, że Bridge pozwala na hierarchię klas obwiedni (analogi klas „opakowujących”), podczas gdy State nie. Wzorce te mają podobne struktury, ale rozwiązują różne problemy: Stan pozwala obiektowi zmieniać swoje zachowanie w zależności od jego stanu wewnętrznego, natomiast Bridge oddziela abstrakcję od jej implementacji, dzięki czemu można je zmieniać niezależnie od siebie.
• Implementacja wzorca Stan opiera się na wzorcu Strategia. Różnice tkwią w ich przeznaczeniu.

Implementacja wzorca State

Rozważmy przykład maszyny o skończonych stanach z dwoma możliwymi stanami i dwoma zdarzeniami.

#włączać używając przestrzeni nazw std; klasa Maszyna ( stan klasy *bieżący; publiczny: Maszyna(); void setCurrent(Stan *s) ( prąd = 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 to); ) void Machine::off() ( current->off(this); ) klasa 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(nowe WŁ.()); Usuń to; ) ); void ON::off(Maszyna *m) ( cout<< " going from ON to OFF"; m->setCurrent(nowe WYŁ.()); Usuń to; ) Maszyna::Machine() ( bieżąca = nowa WYŁ.(); cout<< "\n"; } int main() { void(Machine:: *ptrs)() = { Machine::off, Machine::on }; Machine fsm; int num; while (1) { cout << "Enter 0/1: "; cin >>liczba; (fsm. *ptrs)(); ) )

15.02.2016
21:30

Wzorzec State jest przeznaczony do projektowania klas, które mają wiele niezależnych stanów logicznych. Przejdźmy od razu do przykładu.

Załóżmy, że opracowujemy klasę sterowania kamerą internetową. Kamera może znajdować się w trzech stanach:

1. Nie zainicjowano. Nazwijmy to NotConnectedState;
2. Zainicjalizowany i gotowy do pracy, ale nie są jeszcze przechwytywane żadne klatki. Niech to będzie ReadyState;
3. Aktywny tryb przechwytywania klatek. Oznaczmy ActiveState .

Ponieważ pracujemy ze wzorcem Stanu, najlepiej zacząć od obrazu Diagramu Stanu:

Zamieńmy teraz ten diagram na kod. Aby nie komplikować implementacji, pomijamy kod do pracy z kamerami internetowymi. W razie potrzeby możesz samodzielnie dodać odpowiednie wywołania funkcji bibliotecznych.

Natychmiast udostępnię pełną listę z minimalnymi komentarzami. Następnie omówimy bardziej szczegółowo kluczowe szczegóły tej implementacji.

#włączać #define DECLARE_GET_INSTANCE(NazwaKlasy) \ static ClassName* getInstance() (\ static ClassName instancja;\ return \ ) class WebCamera ( public: typedef std::string Frame; public: // *********** ***************************************** // Wyjątki // ****** ********************************************** Klasa nieobsługiwana: publiczne std: :wyjątek ( ); public: // ***************************************** ******* *********** // Stany // ****************************** ******* **************** klasa NotConnectedState; klasa ReadyState; klasa ActiveState; klasa State ( public: virtual ~State() ( ) virtual void connect(WebCamera*) ( rzut NotSupported(); ) wirtualne rozłączenie (kamera internetowa*) ( std::cout<< "Деинициализируем камеру..." << std::endl; // ... cam->zmieńState(NotConnectedState::getInstance()); ) wirtualny start pustki (WebCamera*) ( rzut NotSupported(); ) wirtualny przystanek pustki (WebCamera*) ( rzut NotSupported(); ) wirtualna ramka getFrame(WebCamera*) ( rzut NotSupported(); ) chroniony: State() ( ) ); // ************************************************** ** klasa NotConnectedState: stan publiczny ( public: DECLARE_GET_INSTANCE(NotConnectedState) void connect(kamera internetowa*) ( std::cout<< "Инициализируем камеру..." << std::endl; // ... cam->zmieńState(ReadyState::getInstance()); ) void rozłącz(WebCamera*) ( rzut NotSupported(); ) prywatny: NotConnectedState() ( ) ); // ************************************************** ** klasa ReadyState: stan publiczny (public: DECLARE_GET_INSTANCE(ReadyState) void start(kamera internetowa*) ( std::cout<< "Запускаем видео-поток..." << std::endl; // ... cam->zmieńState(ActiveState::getInstance()); ) prywatny: ReadyState() ( ) ); // ************************************************** ** klasa ActiveState: stan publiczny (public: DECLARE_GET_INSTANCE(ActiveState) void stop(kamera internetowa*) ( 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->połącz(to); ) void rozłącz() ( m_state->disconnect(this); ) void start() ( m_state->start(this); ) void stop() ( m_state->stop(to); ) Frame getFrame() (zwróć m_state ->getFrame(this); ) private: voidchangeState(State* newState) ( m_state = newState; ) private: int m_camID; Stan* m_stan; );

Zwracam uwagę na makro DECLARE_GET_INSTANCE. Oczywiście odradza się używanie makr w C++. Dotyczy to jednak przypadków, gdy makro pełni funkcję analogową do funkcji szablonowej. W takim przypadku zawsze preferuj to drugie.

W naszym przypadku makro ma na celu zdefiniowanie funkcji statycznej potrzebnej do zaimplementowania . Dlatego jego stosowanie można uznać za uzasadnione. Przecież pozwala ograniczyć duplikację kodu i nie stwarza żadnych poważnych zagrożeń.

Klasy State deklarujemy w klasie głównej - WebCamera. Dla zwięzłości użyłem wbudowanych definicji funkcji składowych wszystkich klas. Jednak w rzeczywistych zastosowaniach lepiej kierować się zaleceniami dotyczącymi rozdzielenia deklaracji i implementacji na pliki h i cpp.

Klasy stanu są deklarowane wewnątrz kamery internetowej, dzięki czemu mają dostęp do prywatnych pól tej klasy. Oczywiście tworzy to niezwykle ścisłe połączenie pomiędzy wszystkimi tymi klasami. Państwa okazują się jednak na tyle specyficzne, że ich ponowne użycie w innych kontekstach nie wchodzi w rachubę.

Podstawą hierarchii klas stanów jest klasa abstrakcyjna WebCamera::State:

Stan klasy ( public: virtual ~State() ( ) wirtualna pustka połącz (kamera internetowa*) ( rzut NotSupported(); ) wirtualna pustka rozłącz (kamera internetowa*) ( std::cout<< "Деинициализируем камеру..." << std::endl; // ... cam->zmieńState(NotConnectedState::getInstance()); ) wirtualny start pustki (WebCamera*) ( rzut NotSupported(); ) wirtualny przystanek pustki (WebCamera*) ( rzut NotSupported(); ) wirtualna ramka getFrame(WebCamera*) ( rzut NotSupported(); ) chroniony: State() ( ) );

Wszystkie jego funkcje członkowskie odpowiadają funkcjom samej klasy WebCamera. Delegowanie bezpośrednie ma miejsce:

Klasa WebCamera ( // ... void connect() ( m_state->connect(this); ) void rozłącz() ( 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; )

Kluczową cechą jest to, że obiekt State akceptuje wskaźnik do instancji WebCamera, która go wywołuje. Dzięki temu można mieć tylko trzy obiekty State dla dowolnie dużej liczby kamer. Możliwość taką uzyskuje się poprzez zastosowanie wzorca Singletona. Oczywiście w kontekście przykładu nie uzyskasz z tego znaczącego zysku. Jednak znajomość tej techniki jest nadal przydatna.

Sama klasa WebCamera nie robi praktycznie nic. Jest całkowicie zależny od swoich Państw. A te państwa z kolei określają warunki wykonywania operacji i zapewniają niezbędny kontekst.

Większość funkcji członkowskich WebCamera::State generuje własne WebCamera::NotSupported . Jest to całkowicie odpowiednie zachowanie domyślne. Na przykład, jeśli ktoś spróbuje zainicjować kamerę, która została już zainicjowana, w naturalny sposób otrzyma wyjątek.

Jednocześnie zapewniamy domyślną implementację WebCamera::State::disconnect(). To zachowanie jest odpowiednie dla dwóch z trzech stanów. Dzięki temu zapobiegamy dublowaniu kodu.

Aby zmienić stan, użyj funkcji członka prywatnego WebCamera::changeState() :

Nieważna zmianaState(Stan* nowyState) ( m_state = newState; )

Teraz do realizacji konkretnych państw. W przypadku WebCamera::NotConnectedState wystarczy zastąpić operacje connect() i rozłączyć():

Klasa NotConnectedState: stan publiczny ( public: DECLARE_GET_INSTANCE(NotConnectedState) void connect(kamera internetowa*) ( std::cout<< "Инициализируем камеру..." << std::endl; // ... cam->zmieńState(ReadyState::getInstance()); ) void rozłącz(WebCamera*) ( rzut NotSupported(); ) prywatny: NotConnectedState() ( ) );

Dla każdego stanu możesz utworzyć pojedynczą instancję. Gwarantujemy to nam deklarując prywatnego konstruktora.

Kolejnym ważnym elementem prezentowanej realizacji jest to, że do nowego Państwa przenosimy się tylko w przypadku powodzenia. Na przykład, jeśli podczas inicjalizacji kamery wystąpi awaria, jest za wcześnie na wejście w stan gotowości. Główną ideą jest pełna zgodność pomiędzy rzeczywistym stanem kamery (w naszym przypadku) a obiektem State.

Zatem aparat jest gotowy do pracy. Utwórzmy odpowiednią klasę WebCamera::ReadyState State:

Klasa ReadyState: stan publiczny (public: DECLARE_GET_INSTANCE(ReadyState) void start(kamera internetowa*) ( std::cout<< "Запускаем видео-поток..." << std::endl; // ... cam->zmieńState(ActiveState::getInstance()); ) prywatny: ReadyState() ( ) );

Ze stanu gotowości możemy przejść do aktywnego stanu przechwytywania ramki. W tym celu udostępniona jest operacja start(), którą zaimplementowaliśmy.

Wreszcie dotarliśmy do ostatniego logicznego stanu kamery, WebCamera::ActiveState:

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

W tym stanie możesz zatrzymać przechwytywanie klatek za pomocą funkcji stop() . W rezultacie zostaniemy przeniesieni z powrotem do WebCamera::ReadyState. Dodatkowo możemy odbierać klatki, które kumulują się w buforze aparatu. Dla uproszczenia przez „ramkę” rozumiemy zwykły ciąg znaków. W rzeczywistości będzie to pewnego rodzaju tablica bajtów.

Teraz możemy zapisać typowy przykład pracy z naszą klasą WebCamera:

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

W rezultacie na konsolę zostanie wyświetlony następujący komunikat:

Zainicjuj kamerę... Rozpocznij strumień wideo... Pobierz bieżącą klatkę... Bieżącą klatkę Zatrzymaj strumień wideo... Deinicjuj kamerę...

Teraz spróbujmy sprowokować błąd. Wywołajmy funkcję connect() dwa razy z rzędu:

Int main() ( WebCamera cam(0); try ( // kamera w stanie NotConnectedState cam.connect(); // kamera w stanie ReadyState // Ale dla tego stanu operacja connect() nie jest dostępna! cam.connect( ); // Zgłasza wyjątek NotSupported ) catch(const WebCamera::NotSupported& e) ( std::cout<< "Произошло исключение!!!" << std::endl; // ... } catch(...) { // Обрабатываем исключение } return 0; }

Oto, co z tego wynika:

Inicjowanie kamery... Wystąpił wyjątek!!! Deinicjujmy kamerę...

Należy pamiętać, że kamera była nadal deinicjowana. Wywołanie funkcji rozłączenia() nastąpiło w destruktorze kamery internetowej. Te. stan wewnętrzny obiektu pozostaje całkowicie poprawny.

wnioski

Korzystając ze wzorca stanu, można w unikalny sposób przekształcić diagram stanu w kod. Na pierwszy rzut oka wdrożenie okazało się szczegółowe. Doszliśmy jednak do jasnego podziału na możliwe konteksty pracy z główną klasą WebCamera. W rezultacie, pisząc o poszczególnych stanach, mogliśmy skoncentrować się na wąskim zadaniu. I to jest najlepszy sposób na pisanie przejrzystego, zrozumiałego i niezawodnego kodu.