WYKŁAD 12 Wzorce projektowe czynnociowe State Mediator
Behavioral Design Pattern: State [obj] Umoliwia obiektowi zmian zachowania gdy zmienia si jego stan wewntrzny. 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: Nawizane, Nasłuchiwane, Zamknite. Gdy otrzymuje dania od klientów powinna zachowywa si w sposób zaleny od aktualnego stanu. Wzorzec State opisuje jak powinna si zachowywa klasa w kadym ze stanów.
Najwaniejsze jest wprowadzenie klasy abstrakcyjnej StanTCP reprezentujcej 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 reprezentujcy biecy stan połczenia. Przekazuje ona wszystkie dania zalene od stanu do tego obiektu (do obiektu podklasy). Przy zmianie stanu obiekt PołczenieTCP zmienia uywany przez siebie obiekt reprezentujcy stan.
Stosowalno: zachowanie obiektu zaley od jego stanu, a obiekt musi zmienia swoje zachowanie w czasie wykonywania programu w zalenoci od stanu operacje zawieraj due wieloczciowe instrukcje warunkowe, które zale od stanu obiektu
Struktura:
Uczestnicy: Kontekst (PołczenieTCP) definiuje interfejs dla klientów utrzymuje egzemplarz podklasy StanuKonkretnego, definiujcy biecy stan Stan (StanTCP) definiuje interfejs do kapsułkowania zachowania zwizanego z okrelonym stanem Kontekstu
StanKonkretny (TCPNawizane, TCPNasłuchiwanie, TCPZamkniete) kada podklasa implementuje zachowanie zwizane ze stanem Kontekstu
Współpraca: Kontekst deleguje dania specyficzne dla stanu do biecego obiektu StanKonkretny Kontekst moe przekazywa siebie samego jako argument do obiektu Stan obsługujcego danie stan ma dostp 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 nastpuje po którym i kiedy moe 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 midzy stanami moliwo współdzielenia obiektów Stan
Implementacja: który z uczestników definiuje przejcia miedzy stanami? alternatywne rozwizanie polegajce na wykorzystaniu tablic tworzenie i niszczenie obiektów Stan wykorzystywanie dynamicznego dziedziczenia
Przykłady Znane zastosowania Pokrewne wzorce: Flyweight wyjania jak mona współdzieli obiekty Stan Singleton obiekty Stan czsto s Singletonami
Behavioral Design Pattern: Mediator [obj]
Przeznaczenie: Wzorzec ten definiuje obiekt kapsułkujcy informacje o tym jak obiekty współdziałaj. W ten sposób przyczynia si on do rozlunienia powiza midzy obiektami (weak-coupling), gdy sprawia, e nie odwołuj si one do siebie bezporednio. Umoliwia 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łoonoci komunikacji pomidzy nimi, a co za tym idzie do komplikacji wzajemnych powiza. Moe si nawet okaza, e kady obiekt musi wiedzie o wszystkich pozostałych. Denie do ponownego uycia przyczynia si do zwikszenia złoonoci, a złoono komunikacji ogranicza moliwoci ponownego uycia.
Przykładem moe by implementacja okienka dialogowego z GUI zawierajcego kontrolki. Kontrolki te s zalene od siebie nawzajem. Np. wybranie czego na licie moe spowodowa zmian tekstu w polu edycyjnym oraz wygaszenie jakich kontrolek. Aby kadorazowo przy implementowaniu kolejnych okienek nie zmienia nieustannie klas reprezentujcych kontrolki w zalenoci od tego jak si one komunikuj z innymi mona zbiorcze zachowanie umieci w osobnym obiekcie mediatorze. Mediator jest odpowiedzialny włanie za sterowanie i koordynowanie interakcji obiektów. Wszystkie obiekty znaj mediatora ale nie znaj siebie nawzajem. [zamiana trójkta w gwiazd]
Moemy sobie wyobrazi okienko dialogowe zajmujce si wyborem czcionki. Rol mediatora moe wtedy pełni klasa KierownikDialoguWybórCzcionki. Zna on kontrolki i koordynuje ich współprac. Jedoczenie kontrolki wiedz o nim. Dziki temu całe zachowanie okienka dialogowego mona zmieni przez wymian jednej klasy.
Stosowalno. zbiór obiektów komunikuje si w dobrze zdefiniowany ale skomplikowany sposób nieuporzdkowane i trudne do zrozumienia współzalenoci utrudnione ponowne uycie obiektu, gdy komunikuje si z wieloma innymi zachowanie rozproszone wró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) kada klasa Współpracownik zna swój obiekt Mediator kady 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łjc dania midzy współpracownikami
Konsekwencje: ograniczenie tworzenia podklas zamiast podklas współpracowników tylko podklasa Mediatora, zatem klasy Współpracowników mona ponownie wykorzystywa rozdzielenie współpracowników rozlunienie powiza pomidzy nimi, mona niezalenie 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 mona oddzieli to jak zachowuj si indywidualnie obiekty od tego jak wyglda komunikacja centralizacja sterowania mediator zamienia złoono współdziałania na złoono mediatora, co moe powodowa trudno w jego utrzymaniu
Implementacja: pomijanie klasy abstrakcyjnej Mediator jeli tylko jeden mediator konkretny komunikacja współpracownik-mediator moe by zaimplementowana z uyciem wzorca Observer (jest nim wtedy Mediator) albo współpracownik moe przesyła w komunikacie samego siebie
Przykłady Zastosowania Pokrewne wzorce: Facade tym si róni od Mediatora, e wyodrbnia 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