WYKŁAD 9. Wzorce projektowe czynnociowe Observer Visitor

Transkrypt

1 WYKŁAD 9 Wzorce projektowe czynnociowe Observer Visitor

2 Behavioral Design Pattern: Observer [obj] Okrela relacj jeden-do-wielu midzy obiektami. Gdy jeden z obiektów zmienia stan, wszystkie obiekty zalene od niego s o tym automatycznie powiadamiane i uaktualniane. Inne nazwy: Publish-Subscribe, Dependents

3 Uzasadnienie: Czsto mamy do czynienia z koniecznoci zaprezentowania danych z jedngo obiektu w innych obiektach na róne sposoby. Zalezy nam te na tym aby obiekty prezentacji nie wiedziały o sobie nawzajem, ale jednoczenie eby zachowywały si tak jakby o sobie wiedziały.

4 Dobrym przykładem jest tu prezentowanie obiektu danych za pomoc zarówno arkusza kalkulacyjnego jak i wykresu słupkowego. Niezalenie od tego gdzie zostanie wprowadzona zmiana stanie si ona od razu widoczna we wszystkich pozostałych obiektach.

5

6 Obiekty obserwowany i obserwator komunikuj si nawzajem. Gdy obserwowany zmienia stan s o tym informowani wszyscy obserwatorzy. W wyniku tego kady obserwator pyta obserwowanego o aktualny stan aby zsynchronizowa z nim swój własny stan.

7 Stosowalno: gdy jaka abstrakcja ma dwa aspekty, jeden zaleny od drugiego (np. widok od danych); kapsułkowanie tych aspektów w oddzielnych obiektach umoliwia niezalene zmienianie i uywanie tych obiektów w czasie wykonania zmiana jednego obiektu wymaga zmiany innych i nie wiadomo ile obiketów trzeba zmieni obiekt powinien by w stanie powiadamia inne obiekty nie przyjmujc adnych załoe co do tego co te obiekty reprezentuj (eliminacja cisłego powizania obiektów) Struktura:

8

9 Uczestnicy: Obserwowany zna swoich obserwatorów (dowoln ilo) zapewnia interfejs dołczania i odłczania obserwatorów Obserwator definiuje interfejs uaktualniania dla obiektów, które powinny by powiadamiane o zmianach, jakie zaszły w obserwowanym

10 ObserwowanyKonkretny przechowuje stan, który interesuje obiekty ObserwatorKonkretny gdy zmienia si jego stan, wysyła powiadomienia do swoich obserwatorów ObserwatorKonkretny utrzymuje odwołanie do obiketu ObserwowanyKonkretny przechowuje stan, który powinien by spójny ze stanem obserwowanego implementuje interfejs obserwatora słucy do uaktualniania, eby zachowa spójno swojego stanu ze stanem obserwowanego

11 Współpraca: ObserwowanyKonkretny zawsze powiadamia swoich obserwatorów, gdy wystpi zmiana, która moe rozsynchronizowa stany. Po otrzymaniu powiadomienia o zmianie, która wystpiła w ObserwowanymKonkretnym, ObserwatorKonkretny moe zapyta go o informacje dotyczce tej zmiany. ObserwatorKonkretny uywa tych informacji do uaktualniania swojego stanu na podstawie stanu obserwowanego.

12 obserwowanykonkretny obserwat orkonkret ny innyobserwatorkonkretny 1: UstawStan() 2: Powiadom() 3: Uaktualnij() 4: PodajStan() 5: Uaktualnij() 6: PodajStan()

13 Naley zwróci uwag na fakt, e obiekt Obserwator, który zainicjował zmian czeka z aktualizacj swojego stanu a do otrzymania powiadomienia od Obserwowanego. Operacja Powiadom nie musi by wołana przez Obserwowanego.

14 Konsekwencje: niezalene zmienianie obserwatorów i obserwowanych moliwo ponownego wykorzystania obserwatorów bez obserwowanego i na odwrót dodawanie obserwatorów bez modyfikowania obserwatorów ani obserwowanego

15 abstrakcyjne powiznie midzy Obserwowanym a Obserwatorem mog by w rónych warstwach aplikacji wsparcie dla rozsyłania komunikatów moliwo usuwania obserwatorów w czasie wykonania nieoczekiwane uaktualnienia obserwatorzy mog nie zdawa sobie sprawy jak lawin komunikatów mog spowodowa przez uaktualnianie obserwatora

16 Implementacja: odwzorowywanie obserwowanych na obserwatorów hash-table obserwowanie wicej ni jednego obserwowanego w celu rozrónienia obserwowany moe przekaza siebie który uczestnik doprowadza do uaktualnienia operacje wyznaczajce stan obserwowanego wołaj Powiadom() zaraz po zmianie stanu klienci odpowiadaj za wołanie Powiadom()

17 zawieszone odwołania do usunitych obserwowanych powiadamianie o usuwaniu aby usun odwołania u obserwatorów zapewnienie, e przed rozesłaniem powiadomienia stan obserwowanego jest spójny aby tego unikn mona wysyła powiadomienie z TemplateMethod w klasach abstrakcyjnych Obserwowanego

18 unikanie protokołów uaktualniania specyficznych dla obserwatora: modele pchajcy (obserwowany wysyła szczegółow informacj o zmianie) i cigncy (obserwatorzy pytaj o interesujce ich szczegóły; wiksze ponowne uycie, ale mniejsza efektywno) jawne specyfikowanie modyfikacji wartych uwagi róni obserwatorzy mog by zainteresowani rónymi zmianami, wtedy rejestruj si wraz ze swoim aspektem

19 kapsułkowanie złoonej semantyki uaktualnie klasa ZarzdcaZmian łczenie klas Obserwowany i Obserwator wspólny interfejs dla obu klas w jzykach bez wielodziedziczenia, wtdy obiekt implementujcy ten interfejs moe działa w kadej z ról

20 Przykłady Zastosowania Pokrewne wzorce: Mediator kapsułkujc złoon sematyk zmian klasa ZarzdcaZmian działa jako Mediator midzy obserwatorami a obserwowanymi Singleton klasa ZarzdcaZmian moe by Singletonem

21 Behavioral Design Pattern: Visitor [obj] Okrela operacj, któa ma by wykonana na elementach struktury obiektowej. Umoliwia definiowanie nowej operacji bez modyfikowania klas elementów, na których ona działa.

22 Uzasadnienie: Przykładem jest kompilator, który reprezentuje programy w postaci drzew składni abstrakcyjnej. Musi on przeprowadza analiz semantyczn (np. sprawdza czy wszystkie zmienne s zdefiniowane). Musi take generowa kod. Na takim drzewie moemy wykonywa cały szereg operacji. Operacje te powinny inaczej traktowa wzły reprezentujce instrukcje, inaczej wzły reprezentujce zmienne, wyraenia arytmtyczne Bd wic dla nich osobne klasy. Zbiór tych klas zaley od jzyka programowania, ale słabo.

23

24 Teraz chodzi nam o to, aby mona było umieszcza nowe operacje bez koniecznoci modyfikowania całej hierarchii i bez umieszczania w klasach kodu, który zajmuje si zupełnie rónymi zagadnieniami (np. generowanie kodu, ładne drukowanie kodu) w ten sposób kompilator bdzie ułatwiał wprowadzanie zmian.

25 Osigniemy te cele jeli wszystkie te operacje wyprowadzimy poza hierarchi umieszczajc je w osobnych klasach. Obiekty tych osobnych klas nosz nazw odwiedzajcych. Odwiedzajcych mona przekaza do elementów hierarchii. W momencie przekazania odwiedzajcego element hierarchii moe przekaza samego siebie do odwiedzajcego, który wykona na nim operacj. T operacj, która dawniej znajdowała si w elemencie hierarchii.

26

27 W ywniku zastosowania tego wzorca otrzymujemy dwie hierarchie klas jedn dla wzłów i drug dla odwiedzajcych. Nowe operacje tworzymy przez dodawanie nowych podklas w hierarchii odwiedzajcych. Dopóki nie zmieni si hierarchia wzłów moemy dodawa w ten sposób nowe operacje.

28 Stosowalno: struktura obiektowa zawiera wiele klas obiektów z rónymi interfejsami i chcemy wykonya na nich operacje zalene od ich klas konkretnych wiele rónych niepowizanych ze sob operacji musi by wykonanych na obiektach struktury, a nie chcemy zanieczyszcza tej struktury tymi operacjami szczególnie przydatne dla współdzielonych struktur klasy definiujce struktur obiektow rzadko si zmieniaj a chcemy czsto definiowa nowe operacje w tej strukturze zmiany w strukturze wymuszaj zmiany całego interfejsu odwiedzajcych

29

30 Uczestnicy: Odwiedzajcy (OdwiedzajcyWzły) deklaruje operacj Odwiedz() dla kadej klasy ElementKonkretny w strukturze obiektowej; nazwa i syngatura operacji okrelaj klas, która wysyła danie Odwied() do Odwiedzajcego; dziki temu Odwiedzajcy moe ustali klas i skorzysta z jej interfejsu

31 OdwiedzajcyKonkretny (OdwiedzajcySprawdzajcyTypy) implementuje kad z operacji zadeklarowanych przez Odwiedzajcego, kazda z operacji definiuje fragment algorytmu zdefiniowanego dla odpowiedniej klasy obiektu w strukturze; OdwiedzajcyKonkretny zapewnia kontekst dla algorytmu i przechowuje jego stan lokalny; stan ten czsto kumuluje wyniki uzyskane podczas przechodzenia struktury

32 Element (Wzeł) definiuje operacj Przyjmij, otrzymujc odwiedzajcego jako argument ElementKonkretny (WzełPrzypisanie, WzełOdwołanieDoZmiennej) implementuje operacj Przyjmij, która otrzymuje odwiedzajcego jako argument

33 StrukturaObiektowa (Program) moe poda swoje elementy moe zapewni wysokopoziomowy interfejs umoliwiajcy odwiedzajcemu odwiedzenie elementów moe by wzorcem Composite lub kolekcj

34 Współpraca: klient musi tworzy obiekt OdwiedzajcyKonkretny, a nastpnie przej struktur obiektow odwiedzajc kady element za pomoc odwiedzajcego gdy element jest odwiedzany wywołuje operacj Odwiedzajcego odpowiedni dla swojej klasy; dostarcza on siebie samego jako argument tej operacji, eby umoliwi odwiedzajcemu dostp do swojego stanu

35 strukturaobiektowaa elementkonkretnya elementkonkretnyb odwiedzajcykonkretny 1: Przyjmij(odwiedzajcy) 2: OdwiedElementKonk ret nya(elementkonkretnya) 3: OperacjaA() 4: Przyjmij(odwiedzajcy) 5: OdwiedElementKonkretnyB(elementKonkretnyB) 6: OperacjaB()

36 Konsekwencje: łatwe dodawanie nowych operacji zebranie razem powizanych ze sob operacji a rozdzielenie niepowizanych trudne dodawanie nowych klas ElementKonkretny odwiedzanie całej hierarchii klas - lepiej ni iterator, bo moe działa na rónych typach kumulowanie stanu naruszanie kapsułkowania operacje dostpu do stanu obiketów klasy ElementKonkretny

37 Implementacja: wywoływanie dwukrotne który z uczestników jest odpowiedzialny za przechodzenie struktury obiektowej?

38 Przykłady Zastosowania Pokrewne wzorce: Composite mona odwiedza hierarchi kompozytu Interpreter zastosowanie do interpretowania