Wzorce projektowe – czynnościowe State Mediator

WYKŁAD 12
Wzorce projektowe – czynno ciowe
State
Mediator
Behavioral Design Pattern: State [obj]
Umo liwia obiektowi zmian zachowania gdy
zmienia si jego stan wewn trzny. Dzieki
temu obiekt zdaje si zmienia swoja klas .
Uzasadnienie:
Klasa Poł czenieTCP reprezentuje poł czenie
sieciowe. Takie poł czenie mo eby w
jednym ze stanów: Nawi zane,
Nasłuchiwane, Zamkni te. Gdy otrzymuje
dania od klientów powinna zachowywa
si w sposób zale ny od aktualnego stanu.
Wzorzec State opisuje jak powinna si
zachowywa klasa w ka dym ze stanów.
Najwa niejsze jest wprowadzenie klasy
abstrakcyjnej StanTCP reprezentuj cej
stany poł czenia sieciowego. Definiuje ona
wspólny interfejs dla swoich podklas, które
implementuj zachowanie specyficzne dla
stanu.
Klasa Poł czenieTCP zawiera w sobie obiekt
StanTCP reprezentuj cy bie cy stan
poł czenia. Przekazuje ona wszystkie
dania zale ne od stanu do tego obiektu
(do obiektu podklasy).
Przy zmianie stanu obiekt Poł czenieTCP
zmienia u ywany przez siebie obiekt
reprezentuj cy stan.
Stosowalno :
• zachowanie obiektu zale y od jego stanu, a
obiekt musi zmienia swoje zachowanie w
czasie wykonywania programu w
zale no ci od stanu
• operacje zawieraj du e wielocz ciowe
instrukcje warunkowe, które zale od stanu
obiektu
Struktura:
Uczestnicy:
• Kontekst (Poł czenieTCP)
– definiuje interfejs dla klientów
– utrzymuje egzemplarz podklasy
StanuKonkretnego, definiuj cy bie cy stan
• Stan (StanTCP)
– definiuje interfejs do kapsułkowania
zachowania zwi zanego z okre lonym stanem
Kontekstu
• StanKonkretny (TCPNawi zane,
TCPNasłuchiwanie, TCPZamkniete)
– ka da podklasa implementuje
zachowanie zwi zane ze stanem
Kontekstu
Współpraca:
• Kontekst deleguje dania specyficzne dla stanu do
bie cego obiektu StanKonkretny
• Kontekst mo e przekazywa siebie samego jako argument
do obiektu Stan obsługuj cego danie – stan ma dost p
do Kontekstu
• Kontekst jest podstawowym interfejsem dla klientów;
Klienci mog konfigurowa Kontekst za pomoc obiektów
Stan; pos konfigurowaniu ju si nie zajmuj stanem
• o tym który stan nast puje po którym i kiedy mo e
decydowa Kontekst albo podklasy KonkretnegoStanu
[maszyna stanów w UML]
Konsekwencje:
• umiejscowienie zachowania specyficznego
dla stanu i rozdzielenie zachowania w
wypadku ró nych stanów
• jawno przej mi dzy stanami
• mo liwo współdzielenia obiektów Stan
Implementacja:
• który z uczestników definiuje przej cia
miedzy stanami?
• alternatywne rozwi zanie polegaj ce na
wykorzystaniu tablic
• tworzenie i niszczenie obiektów Stan
• wykorzystywanie dynamicznego
dziedziczenia
Przykłady
Znane zastosowania
Pokrewne wzorce:
• Flyweight – wyja nia jak mo na
współdzieli obiekty Stan
• Singleton – obiekty Stan cz sto s
Singletonami
Behavioral Design Pattern: Mediator [obj]
Przeznaczenie:
Wzorzec ten definiuje obiekt kapsułkuj cy
informacje o tym jak obiekty współdziałaj .
W ten sposób przyczynia si on do
rozlu nienia powi za mi dzy obiektami
(weak-coupling), gdy sprawia, e nie
odwołuj si one do siebie bezpo rednio.
Umo liwia te oddzielne zmienianie ich
sposobu komunikacji.
Uzasadnienie:
W projektowaniu obiektowym powstaje zwykle
wiele niewielkich klas, których obiekty musz si
komunikowa ze sob nawzajem. Prowadzi to do
wzrostu zło ono ci komunikacji pomi dzy nimi, a
co za tym idzie do komplikacji wzajemnych
powi za . Mo e si nawet okaza , e ka dy obiekt
musi wiedzie o wszystkich pozostałych. D enie
do ponownego u ycia przyczynia si do
zwi kszenia zło ono ci, a zło ono komunikacji
ogranicza mo liwo ci ponownego u ycia.
Przykładem mo e by implementacja okienka dialogowego z
GUI zawieraj cego kontrolki. Kontrolki te s zale ne od
siebie nawzajem. Np. wybranie czego na li cie mo e
spowodowa zmian tekstu w polu edycyjnym oraz
wygaszenie jakich kontrolek. Aby ka dorazowo przy
implementowaniu kolejnych okienek nie zmienia
nieustannie klas reprezentuj cych kontrolki w zale no ci
od tego jak si one komunikuj z innymi mo na zbiorcze
zachowanie umie ci w osobnym obiekcie – mediatorze.
Mediator jest odpowiedzialny wła nie za sterowanie i
koordynowanie interakcji obiektów. Wszystkie obiekty
znaj mediatora ale nie znaj siebie nawzajem. [zamiana
trójk ta w gwiazd ]
Mo emy sobie wyobrazi okienko dialogowe
zajmuj ce si wyborem czcionki. Rol
mediatora mo e wtedy pełni klasa
KierownikDialoguWybórCzcionki. Zna on
kontrolki i koordynuje ich współprac .
Jedocze nie kontrolki wiedz o nim. Dzi ki
temu całe zachowanie okienka dialogowego
mo na zmieni przez wymian jednej klasy.
Stosowalno .
• zbiór obiektów komunikuje si w dobrze
zdefiniowany ale skomplikowany sposób –
nieuporz dkowane i trudne do zrozumienia
współzale no ci
• utrudnione ponowne u ycie obiektu, gdy
komunikuje si z wieloma innymi
• zachowanie rozproszone w ród wielu klas
powinno by modyfikowane bez definowania ich
podklas
Struktura:
Uczestnicy:
• Mediator (KierownikDialogu)
– definiuje interfejs porozumiewania si z
obiektami Współpracownik
• MediatorKonkretny
(KierownikDialoguWybórCzcionki)
– implementuje wspólne zachowanie przez
koordynowanie współpracy obiektów
Współpracownik
– zna i koordynuje swoich współpracowników
• Klasy Współpracowników (ListaRozwijana,
PoleEdycyjne)
– ka da klasa Współpracownik zna swój
obiekt Mediator
– ka dy współpracownik porozumiewa si
ze swoim mediatoremzawsze wtedy gdy
zwykle porozumiewałby si z innym
współpracownikiem
Współpraca:
Współpracownicy wysyłaj komunikaty do
obiektu Mediator i otrzymuj je od niego.
Mediator implementuje wspólne
zachowanie przesył j c dania mi dzy
współpracownikami
Konsekwencje:
• ograniczenie tworzenia podklas – zamiast podklas
współpracowników tylko podklasa Mediatora,
zatem klasy Współpracowników mo na ponownie
wykorzystywa
• rozdzielenie współpracowników – rozlu nienie
powi za pomi dzy nimi, mo na niezale nie
zmienia i ponownie wykorzystywa klasy
Współpracownik i Mediator
• uproszczenie protokołów obiektów – zamiast
wiele-do-wiele mamy jeden-do-wiele, które s
łatwiejsze do maintenance’u
• uabstrakcyjnienie współpracy – mo na oddzieli
to jak zachowuj si indywidualnie obiekty od
tego jak wygl da komunikacja
• centralizacja sterowania – mediator zamienia
zło ono współdziałania na zło ono mediatora,
co mo e powodowa trudno w jego utrzymaniu
Implementacja:
• pomijanie klasy abstrakcyjnej Mediator –
je li tylko jeden mediator konkretny
• komunikacja współpracownik-mediator –
mo e by zaimplementowana z u yciem
wzorca Observer (jest nim wtedy Mediator)
albo współpracownik mo e przesyła w
komunikacie samego siebie
Przykłady
Zastosowania
Pokrewne wzorce:
• Facade – tym si ró ni od Mediatora, e
wyodr bnia podsystem obiektów i zapenia do
niego wygodny interfejs, co oznacza, e tylko on
wysyła dania do podsystemu, ale nie na odwrót.
W Mediatorze komunikacja jest dwukierunkowa
• Observer – współpracownicy mog si
komunikowa z Mediatorem w sposób
zapewniany przez Observer