Wzorce czynnościowe - Łańcuch zobowiązań, Mediator, Metoda szablonowa, Obserwator, Strategia, Stan

Question 1

Wzorce czynnościowe

Answer 1

• łańcuch zobowiązań
• mediator
• metoda szablonowa
• obserwator
• stan
• strategia

Question 2

Łańcuch zobowiązań - nazwy

Answer 2

ang. chain of responsibility

Question 3

Łańcuch zobowiązań - typ

Answer 3

obiektowy, czynnościowy

Question 4

Łańcuch zobowiązań - Przeznaczenie

Answer 4

Pozwala uniknąć wiązania nadawcy żądania z jego odbiorcą, ponieważ umożliwia obsłużenie żądania więcej niż jednemu obiektowi. Łączy w łańcuch obiekty odbiorcze i przekazuje między nimi żądanie do momentu obsłużenia go.

Łańcuch takich obiektów tworzy listę jednokierunkową, w której odpowiedzialność za przetworzone żądanie spada na najlepiej przygotowany do tego obiekt.

Question 5

Łańcuch zobowiązań - Uzasadnienie

Answer 5

Używając systemu pomocy, możemy chcieć uzyskać pomoc dotyczącą konkretnego elementu. Jesli ten element nie obsługuje udzielania pomocy przekaże to następnemu.

Pierwszy obiekt w łańcuchu odbiera żądanie i albo je obsługuje, albo przekazuje do następnego kandydata, a ten robi to samo. Obiekt zgłaszający żądanie nie wie, który obiekt je obsłuży. Można powiedzieć, że żądanie ma niejawnego odbiorcę.

Question 6

Łańcuch zobowiązań - Warunki stosowania

Answer 6

• Kiedy więcej niż jeden obiekt może obsłużyć żądanie, a nie wiadomo z góry, który z nich to zrobi. Obiekt obsługujący żądanie powinien być ustalany automatycznie.
• Jeśli chcesz przesyłać żądanie do jednego z kilku obiektów bez bezpośredniego określania odbiorcy.

Question 7

Łańcuch zobowiązań– Elementy i współdziałanie

Answer 7

• Handler - obiekt obsługujący:

• definiuje interfejs do obsługi żądań;
• (opcjonalnie) obejmuje implementację odwołania do następnika.

• ConcreteHandler - konkretny obiekt obsługujący:

• obsługuje żądania, za które odpowiada;
• może uzyskać dostęp do następnika;
• jeśli obiekt ConcreteHandler potrafi obsłużyć żądanie, robi to; w przeciwnym razie przekazuje je do następnika.

• Client:
- inicjuje żądanie kierowane do obiektu ConcreteHandler wchodzącego w skład łańcucha.

• Kiedy klient zgłosi żądanie, będzie ono przekazywane wzdłuż łańcucha do czasu, kiedy obiekt ConcreteHandler nie podejmie się jego obsługi.

Question 8

Łańcuch zobowiązań– Konsekwencje

Answer 8

• • Zapewnia mniejsze powiązanie. Wzorzec ten sprawia, że obiekty nie muszą wiedzieć, który z innych obiektów obsługuje żądanie. Obiekt potrzebuje jedynie informacji o tym, że żądanie zostanie właściwie obsłużone.
• • Zwiększa elastyczność w zakresie przypisywania zadań obiektom. Łańcuch zobowiązań zwiększa elastyczność przy podziale zadań między obiekty
• • Nie zapewnia gwarancji odbioru żądania. Ponieważ żądanie nie ma jawnego odbiorcy, nie ma gwarancji, że zostanie obsłużone.

Question 9

Łańcuch zobowiązań– Implementacja

Answer 9

• Łączenie następników. Jeśli nie można zdefiniować łańcucha za pomocą istniejących referencji, trzeba je dodać samodzielnie.
• Implementowanie łańcucha następników. Łańcuch następników można zaimplementować na dwa sposoby:
• przez zdefiniowanie nowych powiązań (zwykle w klasie Handler, ale można to zrobić także w klasach ConcreteHandler);
• przez wykorzystanie istniejących powiązań.

• Reprezentowanie żądań. Żądania można reprezentować na różne sposoby. W najprostszej wersji żądanie jest zapisanym na stałe wywołaniem operacji. Jest to wygodne i bezpieczne, jednak pozwala przekazywać tylko stały zestaw żądań zdefiniowanych w klasie Handler. Inna możliwość to zastosowanie pojedynczej funkcji obsługi żądania przyjmującej jako parametr kod żądania (na przykład stałą w postaci liczby całkowitej lub łańcucha znaków).

Question 10

Łańcuch zobowiązań– Powiązane wzorce

Answer 10

Często występuje ze wzorcem kompozyt (obiekt nadrzędny pełni rolę jego następnika)

Question 11

Mediator - nazwy

Answer 11

ang. mediator

Question 12

Mediator - typ

Answer 12

obiektowy, czynnościowy

Question 13

Mediator - Przeznaczenie

Answer 13

Określa obiekt kapsułkujący informacje o interakcji między obiektami z danego zbioru. Wzorzec ten pomaga zapewnić luźne powiązanie, ponieważ zapobiega bezpośredniemu odwoływaniu się obiektów do siebie i umożliwia niezależne modyfikowanie interakcji między nimi. Innymi słowy mediator jest pośrednikiem w komunikacji pomiędzy wieloma obiektami – obiekty te znają tylko mediatora, natomiast mediator zna wszystkie obiekty systemu (topologia gwiazdy).

Question 14

Mediator - Uzasadnienie

Answer 14

• Projekt obiektowy zachęca do rozmieszczania zachowań w różnych obiektach. Może to prowadzić do powstania struktury obiektów z wieloma powiązaniami. W najgorszym przypadku każdy obiekt wie o istnieniu wszystkich pozostałych.
• Między widgetami z okna dialogowego często występują zależności. Na przykład przycisk może być nieaktywny, jeśli określone pole na dane wejściowe jest puste. Zaznaczenie pozycji na liście opcji (tak zwanej liście rozwijanej) może spowodować zmianę zawartości pola na dane wejściowe. I na odwrót — wprowadzenie tekstu w takim polu może spowodować automatyczne zaznaczenie jednej lub kilku pozycji na liście rozwijanej. Kiedy w polu na dane wejściowe pojawi się tekst, system może udostępnić inne przyciski umożliwiające użytkownikowi wykorzystanie tego tekstu, na przykład zmodyfikowanie lub usunięcie elementu, którego on dotyczy.

Question 15

Mediator - Warunki stosowania

Answer 15

• Zestaw obiektów komunikuje się w dobrze zdefiniowany, ale skomplikowany sposób. Powstałe w wyniku tego zależności są nieustrukturyzowane i trudne do zrozumienia.
• Powtórne wykorzystanie obiektu jest trudne, ponieważ odwołuje się on do wielu innych obiektów i komunikuje się z nimi.
• Dostosowanie zachowania rozproszonego po kilku klasach nie powinno wymagać tworzenia wielu podklas.

Question 16

Mediator - Elementy i współdziałanie

Answer 16

• Mediator:
- definiuje interfejs do komunikowania się z obiektami współpracującymi.

• ConcreteMediator:

• zapewnia współdziałanie przez koordynowanie obiektów współpracujących;
• zna powiązane z nim obiekty współpracujące i zarządza nimi.

• Klasy z rodziny Colleague , czyli klasy współpracujące:

• każdy obiekt współpracujący zna powiązany z nią obiekt Mediator;
• każdy obiekt współpracujący komunikuje się z mediatorem zamiast z innymi takimi obiektami.

• Obiekty współpracujące wysyłają i przyjmują żądania za pośrednictwem obiektu Mediator.

Mediator zapewnia współdziałanie przez przekazywanie żądań między odpowiednimi współpracownikami.

Question 17

Mediator - Konsekwencje

Answer 17

• • Ogranicza tworzenie podklas. Mediator pozwala umieścić w jednym miejscu zachowanie, które standardowo trzeba rozproszyć między kilka obiektów.
• • Rozdziela obiekty współpracujące. Mediator ułatwia zachowanie luźnego powiązania między obiektami współpracującymi.
• • Upraszcza protokoły obiektów. Mediator pozwala zastąpić interakcje typu wiele do wielu komunikacją typu jeden do wielu (między mediatorem i powiązanymi z nim współpracownikami).
• +/- Centralizuje sterowanie. Wzorzec Mediator pozwala zamienić złożoność interakcji na złożoność samego mediatora (uwaga na antywzorzec „god class”)

Question 18

Mediator - Implementacja

Answer 18

• Pominięcie klasy abstrakcyjnej Mediator. Jeśli obiekty współpracujące korzystają z tylko jednego mediatora, nie trzeba definiować klasy abstrakcyjnej Mediator.
• Komunikacja między współpracownikami i mediatorem. Obiekty współpracujące muszą komunikować się z mediatorem, kiedy wystąpi istotne zdarzenie. Jedną z możliwości jest zaimplementowanie klasy Mediator jako obserwatora.

Question 19

Mediator - Powiązane wzorce

Answer 19

• Fasada - działa podobnie, jednak jest jednokierunkowa (kieruje żądania do klas podsystemu).
• Obserwator - obiekty współpracujące mogą komunikować się z mediatorem za tego wzorca.

Question 20

Obserwator - nazwy

Answer 20

ang. observer

pol. obiekty zależne
ang. dependents

pol. publikuj-subskrybuj
ang. publish-subscribe

Question 21

Obserwator - typ

Answer 21

obiektowy, czynnościowy

Question 22

Obserwator - Przeznaczenie

Answer 22

Określa zależność jeden do wielu między obiektami. Kiedy zmieni się stan jednego z obiektów, wszystkie obiekty zależne od niego są o tym automatycznie powiadamiane i aktualizowane.

Zaletą użycia tego wzorca projektowego jest luźne powiązanie pomiędzy klasami oraz możliwość dynamicznej zmiany tych powiązań. Klasy obserwatorów jak i obiektów obserwujących nie muszą o sobie wiele wiedzieć, przez co nie tworzą się niepotrzebne zależności.

Question 23

Obserwator - Uzasadnienie

Answer 23

• Typowym efektem ubocznym podziału systemu na kolekcję współdziałających klas jest konieczność zachowania spójności między powiązanymi obiektami. Niepożądane jest jednak osiąganie tego przez tworzenie ściśle powiązanych klas, ponieważ zmniejsza to możliwość ich powtórnego wykorzystania.

Question 24

Obserwator - Warunki stosowania

Answer 24

• Jeśli zmiana w jednym obiekcie wymaga zmodyfikowania drugiego, a nie wiadomo, ile obiektów trzeba przekształcić.
• Jeżeli obiekt powinien móc powiadamiać inne bez określania ich rodzaju. Oznacza to, że obiekty nie powinny być ściśle powiązane.

Question 25

Obserwator - Elementy i współdziałanie

Answer 25

• Subject, czyli podmiot:

• zna powiązane z nim obserwatory; podmiot może obserwować dowolna liczba obiektów Observer;
• udostępnia interfejs do dołączania i odłączania obiektów Observer.
• Observer: - definiuje interfejs do aktualizacji dla obiektów, które należy powiadamiać o zmianach podmiotu.
• ConcreteSubject, czyli podmiot konkretny:
• przechowuje stan istotny dla obiektów ConcreteObserver;
• kiedy zmieni się jego stan, wysyła powiadomienie do powiązanych z nim obserwatorów.

• ConcreteObserver:

• przechowuje referencję do obiektu ConcreteSubject;
• przechowuje stan, który powinien być spójny ze stanem podmiotu;
• obejmuje implementację interfejsu do aktualizacji z klasy Observer potrzebną do tego, aby zachować spójność stanu obiektu ConcreteObserver ze stanem podmiotu.

• Obiekt ConcreteSubject powiadamia obserwatory o każdej zmianie, która mogłaby spowodować, że stan tego obiektu będzie niespójny ze stanem obserwatorów. Obiekt ConcreteObserver po otrzymaniu powiadomienia o zmianie obiektu ConcreteSubject może wysłać do niego zapytanie o informacje. Na podstawie tych danych obiekt ConcreteObserver dostosowuje swój stan do stanu podmiotu.

Question 26

Obserwator - Konsekwencje

Answer 26

• • Abstrakcyjne powiązanie między obiektami Subject i Observer. Podmiot zna tylko listę obserwatorów, a każdy z nich jest zgodny z prostym interfejsem klasy abstrakcyjnej Observer. Podmiot nie zna klasy konkretnej żadnego z obserwatorów. Dlatego powiązanie między podmiotami i obserwatorami jest abstrakcyjne i minimalne.
• • Obsługa rozsyłania grupowego komunikatów. Podmiot przy wysyłaniu powiadomień — inaczej niż w przypadku zwykłych żądań — nie musi określać odbiorcy.
• • Nieoczekiwane aktualizacje. Ponieważ obserwatory nie wiedzą o swoim istnieniu, mogą nie znać ostatecznych kosztów zmodyfikowania podmiotu. Na pozór bezpieczna operacja na obiekcie może spowodować kaskadę aktualizacji w obserwatorach i zależnych od nich obiektach.

Question 27

Obserwator - Implementacja

Answer 27

• Kapsulkowanie złożonej semantyki aktualizacji. Jeśli relacja zależności między podmiotami i obserwatorami jest wyjątkowo złożona, czasem potrzebny jest obiekt do zarządzania takimi związkami. Nazwijmy taki obiekt ChangeManager.
• Odwzorowywanie podmiotów na obserwatory. Najprostszy sposób na śledzenie w podmiocie obserwatorów otrzymujących powiadomienia polega na przechowywaniu referencji do nich bezpośrednio w podmiocie. Jednak to podejście może okazać się zbyt kosztowne, jeśli istnieje wiele podmiotów i nieliczne obserwatory. Jednym z rozwiązań jest zamiana kosztów pamięci na koszty w postaci czasu przetwarzania przez zastosowanie wyszukiwania asocjacyjnego do przechowywania odwzorowań podmiotów na obserwatory. Wtedy podmiot bez obserwatorów nie będzie powodował dodatkowych narzutów związanych z pamięcią. Jednak to podejście zwiększa koszt uzyskania dostępu do obserwatora.
• Obserwowanie więcej niż jednego podmiotu. W niektórych sytuacjach uzasadnione jest uzależnienie obserwatora od więcej niż jednego podmiotu. Na przykład arkusz kalkulacyjny może zależeć od kilku źródeł danych.
• Wiszące referencje do usuniętych podmiotów. Usunięcie podmiotu nie powinno prowadzić do powstawania wiszących referencji w jego obserwatorach.

Question 28

Obserwator - Powiązane wzorce

Answer 28

• Mediator - z uwagi na kapsułkowanie złożonej semantyki aktualizacji klasa ChangeManager działa jak mediator między podmiotami i obserwatorami.
• Singleton - do utworzenia klasy ChangeManager można zastosować wzorzec Singleton, aby jej egzemplarz był niepowtarzalny i globalnie dostępny

Question 29

Metoda szablonowa - nazwy

Answer 29

ang. template method

Question 30

Metoda szablonowa - typ

Answer 30

klasowy, czynnościowy

Question 31

Metoda szablonowa - Przeznaczenie

Answer 31

Określa szkielet algorytmu i pozostawia doprecyzowanie niektórych jego kroków podklasom. Umożliwia modyfikację niektórych etapów algorytmu w podklasach bez zmiany jego struktury.

Zaletą stosowania tego wzorca projektowego jest możliwość zdefiniowania algorytmu, którego wybrane części mogą być w dowolny sposób modyfikowane. Kod nie jest duplikowany, jest przejrzysty, a dodawanie nowych wersji algorytmu jest prostsze i szybsze.

Question 32

Metoda szablonowa - Uzasadnienie

Answer 32

Zastanówmy się nad platformą do tworzenia aplikacji udostępniającą klasy Application i Document. Klasa Application odpowiada za otwieranie istniejących dokumentów zapisanych w formacie zewnętrznym, na przykład w pliku. Obiekt Document reprezentuje informacje z dokumentu po ich wczytaniu z pliku. W aplikacjach budowanych za pomocą wspomnianej platformy można utworzyć podklasy klas Application i Document dostosowane do specyficznych potrzeb. Na przykład w aplikacji do rysowania zdefiniowane zostaną podklasy DrawApplication i DrawDocument, a w aplikacji do przetwarzania arkuszy kalkulacyjnych — podklasy SpreadsheetApplication i SpreadsheetDocument.

Question 33

Metoda szablonowa - Warunki stosowania

Answer 33

• Do jednorazowego implementowania niezmiennych części algorytmu i umożliwienia implementowania zmieniających się zachowań w podklasach.
• Kiedy zachowanie wspólne dla podklas należy wyodrębnić i umieścić w jednej klasie, aby uniknąć powielania kodu.
• Do kontrolowania rozszerzania podklas. Można zdefiniować metodę szablonową wywołującą w odpowiednich miejscach operacje stanowiące „punkty zaczepienia”, co umożliwia rozszerzanie podklas tylko w tych punktach.

Question 34

Metoda szablonowa - Elementy i współdziałanie

Answer 34

• AbstractClass - określa abstrakcyjne operacje proste definiowane w podklasach konkretnych w celu zaimplementowania etapów algorytmu;
- obejmuje implementację metody szablonowej definiującej szkielet algorytmu; metoda szablonowa wywołuje operacje proste, a także operacje zdefiniowane w klasie AbstractClass lub w innych klasach.

• ConcreteClass - obejmuje implementację operacji prostych realizujących specyficzne dla podklasy etapy algorytmu.
• Obiekt ConcreteClass polega na obiekcie AbstractClass w zakresie implementacji niezmiennych kroków algorytmu

Question 35

Metoda szablonowa - Konsekwencje

Answer 35

• To podstawowa technika powtórnego wykorzystania kodu. Są szczególnie istotne w bibliotekach klas, ponieważ stanowią narzędzie do wyodrębniania wspólnego zachowania w klasach biblioteki.
• Metody szablonowe prowadzą do odwrócenia struktury sterowania. Wynika to z tego, że klasa nadrzędna wywołuje operacje podklasy, a nie na odwrót.
• Ważne jest, aby w metodzie szablonowej określić, które operacje to „punkty zaczepienia” (można je przesłonić), a które są operacjami abstrakcyjnymi (trzeba je przesłonić). Aby skutecznie powtórnie wykorzystać klasę abstrakcyjną, autor podklasy musi zrozumieć, które operacje zaprojektowano w celu ich przesłonięcia.

Question 36

Metoda szablonowa - Implementacja

Answer 36

• Minimalizowanie liczby operacji prostych. Ważnym celem w czasie projektowania metod szablonowych jest zminimalizowanie liczby operacji prostych, które trzeba przesłonić w podklasie w celu utworzenia ciała algorytmu.
• Konwencje nazewnicze. Można wyróżnić przeznaczone do przesłonięcia operacje przez dodanie przedrostka do ich nazw. Na przykład „Do”- DoCreateDocument, DoRead itd.

Question 37

Metoda szablonowa - Powiązane wzorce

Answer 37

• Metoda wytwórcza - jest często wywoływana przez metody szablonowe.
• Strategia - w metodach szablonowych wykorzystywane jest dziedziczenie do modyfikowania fragmentów algorytmu. W przypadku strategii za pomocą delegowania zmieniany jest cały algorytm.

Question 38

Strategia - nazwy

Answer 38

ang. strategy

pol. polityka
ang. policy

Question 39

Strategia - typ

Answer 39

obiektowy, czynnościowy

Question 40

Strategia - Przeznaczenie

Answer 40

Wzorzec Strategia definiuje rodzinę algorytmów, pakuje je jako osobne klasy i powoduje, że są one w pełni wymienne.

Zastosowanie tego wzorca pozwala na to, aby zmiany w implementacji algorytmów przetwarzania były całkowicie niezależne od strony klienta, który z nich korzysta

Question 41

Strategia - Uzasadnienie

Answer 41

• Istnieje wiele algorytmów podziału strumienia tekstu na wiersze. Trwałe wbudowanie wszystkich takich algorytmów w potrzebujące ich klasy nie jest pożądane.

Question 42

Strategia - Warunki stosowania

Answer 42

• Kiedy wiele powiązanych klas różni się tylko zachowaniem. Strategie umożliwiają skonfigurowanie klasy za pomocą jednego z wielu zachowań.
• Jeśli potrzebne są różne wersje algorytmu. Można na przykład zdefiniować algorytmy związane z różnymi korzyściami i kosztami z zakresu pamięci oraz czasu przetwarzania.
• Jeżeli algorytm korzysta z danych, o których klienty nie powinny wiedzieć. Wzorzec Strategia pozwala uniknąć ujawniania złożonych, specyficznych dla algorytmu struktur danych.
• Gdy klasa definiuje wiele zachowań, a te w operacjach pojawiają się w formie złożonych instrukcji warunkowych. Zamiast tworzyć wiele takich instrukcji, należy przenieść powiązane gałęzie do odrębnych klas Strategy.

Question 43

Strategia - Elementy i współdziałanie

Answer 43

• Strategy - obejmuje deklarację wspólnego interfejsu wszystkich obsługiwanych algorytmów. Klasa Context może korzystać z tego interfejsu do wywoływania algorytmów zdefiniowanych w klasach ConcreteStrategy.

• ConcreteStrategy
- obejmuje implementację algorytmu zgodną z interfejsem klasy Strategy.

• Context - jest konfigurowana za pomocą obiektu ConcreteStrategy;

• przechowuje referencję do obiektu Strategy;
• może definiować interfejs dający obiektom Strategy dostęp do danych obiektu Context.
• Klasy Strategy i Context współdziałają w celu realizacji wybranego algorytmu. Obiekt Context może w momencie wywołania algorytmu przekazać do obiektu Strategy wszystkie dane potrzebne w tym algorytmie.
• Inne rozwiązanie to przekazywanie przez obiekt Context samego siebie jako argumentu do operacji klasy Strategy. Umożliwia to obiektom Strategy zwrotne wywołanie obiektu Context w razie potrzeby.
• Obiekt Context przekazuje żądania od jego klientów do obiektu Strategy. Klienty zwykle tworzą obiekt ConcreteStrategy i przekazują go do obiektu Context. Następnie klienty mogą kontaktować się tylko z obiektem Context. Często klienty mogą wybierać klasy z całej rodziny klas ContextStrategy.

Question 44

Strategia - Konsekwencje

Answer 44

• Powoduje powstawanie rodzin powiązanych algorytmów.
• Zapewnia alternatywę dla tworzenia podklas.
• Strategie pozwalają wyeliminować instrukcje warunkowe. Wzorzec Strategia można zastosować zamiast instrukcji warunkowych do wyboru pożądanego zachowania. Kiedy różne zachowania są umieszczone w jednej klasie, trudno jest uniknąć korzystania z instrukcji warunkowych do ustalenia właściwego z nich.

Question 45

Strategia - Implementacja

Answer 45

• Definiowanie interfejsów klas Strategy i Context. Interfejsy klas Strategy i Context muszą zapewniać obiektom ConcreteStrategy wydajny dostęp do wszelkich potrzebnych im danych z obiektu Context i na odwrót.
• Opcjonalne stosowanie obiektów Strategy. Klasę Context można uprościć, jeśli może ona działać bez obiektu Strategy. Obiekt Context powinien wtedy sprawdzać, czy obiekt Strategy jest dostępny, a dopiero potem z niego korzystać. Jeśli obiekt Strategy istnieje, obiekt Context będzie stosował go w standardowy sposób. Jeżeli strategia jest niedostępna, obiekt Context wykorzysta standardowe zachowanie.

Question 46

Strategia - Powiązane wzorce

Answer 46

• Pyłek - obiekty Strategy często warto tworzyć jako pyłki.

Question 47

Stan - nazwa

Answer 47

ang. state

pol. obiekty stanów
ang. objects of states

Question 48

Stan - typ

Answer 48

obiektowy, czynnościowy

Question 49

Stan - Przeznaczenie

Answer 49

Umożliwia obiektowi modyfikację zachowania w wyniku zmiany wewnętrznego stanu. Wygląda to tak, jakby obiekt zmienił klasę.

Question 50

Stan - Uzasadnienie

Answer 50

Zastanówmy się nad klasą TCPConnection reprezentującą połączenie sieciowe. Obiekt tej klasy
przyjmuje kilka stanów — Established (po nawiązaniu), Listening (oczekiwanie), Closed (po zamknięciu). Kiedy obiekt TCPConnection odbiera żądania od innych obiektów, reaguje w różny sposób w zależności od stanu. Na przykład efekt żądania Open jest oparty na tym, czy połączenie znajduje się w stanie Close czy Established. Wzorzec Stan opisuje, jak obiekt TCPConnection może zmieniać zachowania w zależności od stanu.

Question 51

Stan - Warunki stosowania

Answer 51

• Zachowanie obiektu zależy od jego stanu, a obiekt musi na podstawie stanu zmieniać działanie w czasie wykonywania programu.

Question 52

Stan - Elementy i współdziałanie

Answer 52

• Context:
- definiuje interfejs udostępniany klientom;
- przechowuje egzemplarz podklasy klasy ConcreteState definiujący bieżący stan.
• State:
- definiuje interfejs do kapsułkowania zachowania związanego z określonym stanem obiektu
Context.
• Podklasy klasy ConcreteState:
- każda podklasa obejmuje implementację zachowania powiązaną ze stanem obiektu Context.

Obiekt Context deleguje żądania specyficzne dla stanu do bieżącego obiektu ConcreteState. Obiekt Context może przekazać sam siebie jako argument do obiektu State obsługującego żądanie. Umożliwia to obiektowi State uzyskanie w razie potrzeby dostępu do kontekstu. Obiekt Context to podstawowy interfejs dla klientów. Klienty mogą konfigurować interfejs tego obiektu za pomocą obiektów State. Po skonfigurowaniu obiektu Context klienty nie muszą bezpośrednio korzystać z obiektów State. Klasa Context lub podklasy klasy ConcreteState mogą określać kolejność i warunki zmiany stanów.

Question 53

Stan - Konsekwencje

Answer 53

• Pozwala umieścić w jednym miejscu zachowanie specyficzne dla stanu i rozdzielić zachowania
powiązane z różnymi stanami.
• Powoduje, że zmiany stanu są jawne. Kiedy stan obiektu jest zdefiniowany całkowicie w kategoriach wewnętrznych wartości jego danych, zmiany stanu nie mają jawnej reprezentacji, ale wynikają z przypisania wartości do określonych zmiennych. Wprowadzenie odrębnych obiektów dla różnych stanów zapewnia większą jawność zmian stanu.
• Stan obiektów można współużytkować (pyłek).

Question 54

Stan - Implementacja

Answer 54

• Który z elementów ma definiować zmiany stanu? Wzorzec Stan nie określa, które elementy mają definiować kryteria zmiany stanu. Jeśli te kryteria są stałe, można je w całości zapisać w klasie Context. Jednak zwykle elastyczniejsze i bardziej odpowiednie jest umożliwienie podklasom klasy State samodzielnego określania następnego stanu oraz momentu jego zmiany
• Podejście oparte na tablicach. Dla każdego stanu tablica odwzorowuje wszystkie możliwe dane wejściowe prowadzące do następnego stanu. Prowadzi do przekształcenia kodu z instrukcjami
warunkowymi w kod oparty na przeszukiwaniu tablicy.
• Tworzenie i usuwanie obiektów State. W czasie implementowania warto zastanowić się nad typowym dylematem:
• - czy tworzyć obiekty State tylko wtedy, kiedy są potrzebne, a następnie je usuwać
• - czy tworzyć je na początku działania programu i nigdy ich nie likwidować.

Question 55

Stan - Powiązane wzorce

Answer 55

• Wzorzec Pyłek określa, kiedy i jak można współużytkować obiekty State.
• Obiekty State często są singletonami.