2.1 Stan
Stan jest behawioralnym wzorcem projektowym. Jest używany w tych przypadkach, gdy podczas wykonywania programu obiekt musi zmienić swoje zachowanie w zależności od swojego stanu.
![Państwo](https://cdn.codegym.cc/images/article/0b64173f-b514-4ae1-a073-6cbb386a5716/800.jpeg)
Wzór składa się z 3 bloków:
Kontekst to klasa, której obiekty powinny zmieniać swoje zachowanie w zależności od stanu.
Stan jest interfejsem, który musi zaimplementować każdy z konkretnych stanów. Poprzez ten interfejs obiekt Context wchodzi w interakcję ze stanem, delegując do niego wywołania metod. Interfejs powinien zawierać środki do przekazywania informacji zwrotnej do obiektu, którego zachowanie ma zostać zmienione.
W tym celu wykorzystywane jest zdarzenie (wzorzec Wydawca - Subskrybent). Jest to konieczne w celu zastąpienia obiektu stanu podczas wykonywania programu w przypadku wystąpienia zdarzeń. Mogą wystąpić przypadki, w których sam kontekst okresowo odpytuje obiekt stanu pod kątem przejścia.
ConcreteState1, ConcreteState2 - klasy stanów konkretnych. Powinien zawierać informację o tym, w jakich warunkach iw jakich stanach obiekt może przejść ze stanu obecnego. Na przykład ze Stanu Konkretu 1 obiekt może przejść do Stanu Konkretu 2 i Stanu Konkretu 3, a ze Stanu Konkretu 2 z powrotem do Stanu Konkretu 1 i tak dalej. Obiekt jednego z nich musi zawierać Kontekst po utworzeniu.
Na przykład piszesz grę, w której postać może biegać, pływać i latać. Jeśli twoja postać dostała się do wody, rozsądne jest ograniczenie jej zachowania w wodzie: teraz nie może strzelać, ale wciąż ma kilka akcji: pływanie do przodu, w prawo, w lewo itp.
Stan twojej postaci można opisać za pomocą obiektu State, który ma metody, które można wywołać i które coś zrobią. A kiedy twoja postać znajdzie się w wodzie, po prostu zmieniasz odniesienie do innego obiektu stanu w środku - i zmienia się jego stan.
2.2 strategia
Strategia to behawioralny wzorzec projektowy służący do definiowania rodziny algorytmów, hermetyzacji każdego z nich i uczynienia ich wymiennymi. Pozwala to na wybór algorytmu poprzez zdefiniowanie odpowiedniej klasy.
Wzorzec Strategia umożliwia zmianę wybranego algorytmu niezależnie od obiektów klienckich, które go używają.
![Strategia](https://cdn.codegym.cc/images/article/673c4c44-ec33-4d4e-860f-399abc388d8d/800.jpeg)
Wzorzec Strategia umożliwia stosowanie różnych reguł biznesowych lub algorytmów w zależności od kontekstu. Stosowany jest w przypadkach, gdy w tym samym miejscu muszą być zastosowane różne algorytmy w zależności od aktualnego stanu systemu (lub jego otoczenia).
Silne strony:
- enkapsulacja implementacji różnych algorytmów, system uniezależnia się od ewentualnych zmian reguł biznesowych;
- wywołanie wszystkich algorytmów w jeden standardowy sposób;
- nieużywanie przełączników i/lub instrukcji warunkowych.
Ten wzorzec jest nieco podobny do wzorca Stanu, ale tutaj nacisk kładziony jest nie na stan, ale na zachowanie. Załóżmy, że postać w twojej grze może zmieniać broń. Następnie zmieniając broń, możesz po prostu zmienić odniesienie do obiektu opisującego działanie tej broni.
2.3 Metoda szablonowa
![Metoda szablonowa](https://cdn.codegym.cc/images/article/be4df3de-e667-4f4d-9ea7-d3b021879bb2/800.jpeg)
Klasa abstrakcyjna (klasa abstrakcyjna) – definiuje operacje abstrakcyjne, które są zastępowane w spadkobiercach w celu realizacji kroków algorytmu; implementuje metodę szablonu, która definiuje szkielet algorytmu. Metoda szablonu wywołuje operacje zamiany i inne zdefiniowane w klasie Abstract.
Klasa betonu (klasa betonu) – realizuje zastąpione operacje w sposób niezbędny do realizacji. Klasa Concrete zakłada, że niezmienne kroki algorytmu będą wykonywane w klasie AbstractClass.
Ten wzór jest często używany w razie potrzeby:
- Jednorazowe użycie niezmiennej części algorytmu, pozostawiając część zmienną w gestii spadkobierców.
- Lokalizacja i izolacja kodu wspólnego dla kilku klas w celu uniknięcia powielania.
- Zezwalaj spadkobiercom na rozszerzanie kodu tylko w określonych miejscach.
Tak, ten wzorzec opisuje użycie pary: klasy abstrakcyjnej i jej implementacji.
2.4 Łańcuch odpowiedzialności
Łańcuch odpowiedzialności to behawioralny wzorzec projektowy zaprojektowany do organizowania poziomów odpowiedzialności w systemie.
![Łańcuch odpowiedzialności](https://cdn.codegym.cc/images/article/41b55822-dc67-4db3-a0e8-b467bc9f320d/800.jpeg)
Szablon zalecany jest do stosowania w warunkach, w których:
- w opracowanym systemie istnieje grupa obiektów, które mogą przetwarzać komunikaty określonego typu;
- wszystkie komunikaty muszą być przetwarzane przez co najmniej jeden obiekt systemowy;
- komunikaty w systemie są przetwarzane zgodnie ze schematem „przetwarzaj sam lub przekaż do innego”, to znaczy niektóre komunikaty są przetwarzane na poziomie, z którego zostały odebrane, a inne są przekazywane do obiektów innego poziomu.
2.5 Pamiątka
Keeper (Memento) to behawioralny wzorzec projektowy, który umożliwia naprawianie i zapisywanie wewnętrznego stanu obiektu bez naruszania hermetyzacji, dzięki czemu można go później przywrócić do tego stanu.
![Strażnik (pamiątka)](https://cdn.codegym.cc/images/article/9b1d2d68-74b7-427c-8d7b-cf44640cf51f/800.jpeg)
Wzór Guardian jest używany, gdy:
- konieczne jest zapisanie migawki stanu obiektu (lub jego części) do późniejszego przywrócenia;
- Bezpośredni interfejs do pobierania stanu obiektu ujawnia szczegóły implementacji i przerywa enkapsulację obiektu.
GO TO FULL VERSION