Wzorce projektowe – czynnościowe Observer Visitor

WYKŁAD 9
Wzorce projektowe – czynno ciowe
Observer
Visitor
Behavioral Design Pattern: Observer [obj]
Okre la relacj jeden-do-wielu mi dzy
obiektami. Gdy jeden z obiektów zmienia
stan, wszystkie obiekty zale ne od niego s
o tym automatycznie powiadamiane i
uaktualniane.
Inne nazwy: Publish-Subscribe, Dependents
Uzasadnienie:
Cz sto mamy do czynienia z konieczno ci
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
jednocze nie eby zachowywały si tak
jakby o sobie wiedziały.
Dobrym przykładem jest tu prezentowanie
obiektu danych za pomoc zarówno arkusza
kalkulacyjnego jak i wykresu słupkowego.
Niezale nie od tego gdzie zostanie
wprowadzona zmiana stanie si ona od razu
widoczna we wszystkich pozostałych
obiektach.
Obiekty obserwowany i obserwator
komunikuj si nawzajem. Gdy
obserwowany zmienia stan s o tym
informowani wszyscy obserwatorzy. W
wyniku tego ka dy obserwator pyta
obserwowanego o aktualny stan aby
zsynchronizowa z nim swój własny stan.
Stosowalno :
• gdy jaka abstrakcja ma dwa aspekty, jeden zale ny od
drugiego (np. widok od danych); kapsułkowanie tych
aspektów w oddzielnych obiektach umo liwia niezale ne
zmienianie i u ywanie 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 przyjmuj c adnych zało e co do tego co te obiekty
reprezentuj (eliminacja cisłego powi zania obiektów)
Struktura:
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
• 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łu cy do
uaktualniania, eby zachowa spójno swojego stanu
ze stanem obserwowanego
Współpraca:
ObserwowanyKonkretny zawsze powiadamia
swoich obserwatorów, gdy wyst pi zmiana, która
mo e rozsynchronizowa stany.
Po otrzymaniu powiadomienia o zmianie, która
wyst piła w ObserwowanymKonkretnym,
ObserwatorKonkretny mo e zapyta go o
informacje dotycz ce tej zmiany.
ObserwatorKonkretny u ywa tych informacji do
uaktualniania swojego stanu na podstawie stanu
obserwowanego.
obserwowanyKonkretny
obserwat orKonkret ny
1: UstawStan()
2: Powiadom()
3: Uaktualnij()
4: PodajStan()
5: Uaktualnij()
6: PodajStan()
innyObserwatorKonkretny
Nale y 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.
Konsekwencje:
• niezale ne zmienianie obserwatorów i
obserwowanych
• mo liwo ponownego wykorzystania
obserwatorów bez obserwowanego i na odwrót
• dodawanie obserwatorów bez modyfikowania
obserwatorów ani obserwowanego
• abstrakcyjne powi znie mi dzy Obserwowanym a
Obserwatorem – mog by w ró nych warstwach
aplikacji
• wsparcie dla rozsyłania komunikatów –
mo liwo usuwania obserwatorów w czasie
wykonania
• nieoczekiwane uaktualnienia – obserwatorzy
mog nie zdawa sobie sprawy jak lawin
komunikatów mog spowodowa przez
uaktualnianie obserwatora
Implementacja:
• odwzorowywanie obserwowanych na
obserwatorów – hash-table
• obserwowanie wi cej ni jednego obserwowanego
– w celu rozró nienia obserwowany mo e
przekaza siebie
• który uczestnik doprowadza do uaktualnienia
– operacje wyznaczaj ce stan obserwowanego
wołaj Powiadom() zaraz po zmianie stanu
– klienci odpowiadaj za wołanie Powiadom()
• zawieszone odwołania do usuni tych
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 mo na wysyła
powiadomienie z TemplateMethod w
klasach abstrakcyjnych Obserwowanego
• unikanie protokołów uaktualniania specyficznych
dla obserwatora: modele pchaj cy (obserwowany
wysyła szczegółow informacj o zmianie) i
ci gn cy (obserwatorzy pytaj o interesuj ce ich
szczegóły; wi ksze ponowne u ycie, ale mniejsza
efektywno )
• jawne specyfikowanie modyfikacji wartych uwagi
– ró ni obserwatorzy mog by zainteresowani
ró nymi zmianami, wtedy rejestruj si wraz ze
swoim aspektem
• kapsułkowanie zło onej semantyki
uaktualnie – klasa Zarz dcaZmian
• ł czenie klas Obserwowany i Obserwator –
wspólny interfejs dla obu klas w j zykach
bez wielodziedziczenia, wtdy obiekt
implementuj cy ten interfejs mo e działa
w ka dej z ról
Przykłady
Zastosowania
Pokrewne wzorce:
• Mediator – kapsułkuj c zło on sematyk zmian
klasa Zarz dcaZmian działa jako Mediator mi dzy
obserwatorami a obserwowanymi
• Singleton – klasa Zarz dcaZmian mo e by
Singletonem
Behavioral Design Pattern: Visitor [obj]
Okre la operacj , któa ma by wykonana na
elementach struktury obiektowej.
Umo liwia definiowanie nowej operacji bez
modyfikowania klas elementów, na których
ona działa.
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 tak e
generowa kod. Na takim drzewie mo emy wykonywa
cały szereg operacji. Operacje te powinny inaczej
traktowa w zły reprezentuj ce instrukcje, inaczej w zły
reprezentuj ce zmienne, wyra enia arytmtyczne… B d
wi c dla nich osobne klasy. Zbiór tych klas zale y od
j zyka programowania, ale słabo.
Teraz chodzi nam o to, aby mo na było
umieszcza nowe operacje bez konieczno ci
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 b dzie ułatwiał wprowadzanie
zmian.
Osi gniemy te cele je li wszystkie te operacje
wyprowadzimy poza hierarchi umieszczaj c je w
osobnych klasach. Obiekty tych osobnych klas
nosz nazw odwiedzaj cych. Odwiedzaj cych
mo na przekaza do elementów hierarchii. W
momencie przekazania odwiedzaj cego element
hierarchii mo e przekaza samego siebie do
odwiedzaj cego, który wykona na nim operacj .
T operacj , która dawniej znajdowała si w
elemencie hierarchii.
W ywniku zastosowania tego wzorca
otrzymujemy dwie hierarchie klas – jedn
dla w złów i drug dla odwiedzaj cych.
Nowe operacje tworzymy przez dodawanie
nowych podklas w hierarchii
odwiedzaj cych. Dopóki nie zmieni si
hierarchia w złów mo emy dodawa w ten
sposób nowe operacje.
Stosowalno :
•
struktura obiektowa zawiera wiele klas obiektów z
ró nymi interfejsami i chcemy wykonya na nich
operacje zale ne od ich klas konkretnych
•
wiele ró nych niepowi zanych 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 definiuj ce struktur obiektow rzadko si
zmieniaj a chcemy cz sto definiowa nowe operacje w
tej strukturze – zmiany w strukturze wymuszaj zmiany
całego interfejsu odwiedzaj cych
Uczestnicy:
• Odwiedzaj cy (Odwiedzaj cyW zły)
– deklaruje operacj Odwiedz() dla ka dej
klasy ElementKonkretny w strukturze
obiektowej; nazwa i syngatura operacji
okre laj klas , która wysyła danie
Odwied () do Odwiedzaj cego; dzi ki
temu Odwiedzaj cy mo e ustali klas i
skorzysta z jej interfejsu
• Odwiedzaj cyKonkretny
(Odwiedzaj cySprawdzaj cyTypy)
– implementuje ka d z operacji
zadeklarowanych przez Odwiedzaj cego, kazda
z operacji definiuje fragment algorytmu
zdefiniowanego dla odpowiedniej klasy obiektu
w strukturze; Odwiedzaj cyKonkretny
zapewnia kontekst dla algorytmu i przechowuje
jego stan lokalny; stan ten cz sto kumuluje
wyniki uzyskane podczas przechodzenia
struktury
• Element (W zeł)
– definiuje operacj Przyjmij, otrzymuj c
odwiedzaj cego jako argument
• ElementKonkretny (W zełPrzypisanie,
W zełOdwołanieDoZmiennej)
– implementuje operacj Przyjmij, która
otrzymuje odwiedzaj cego jako argument
• StrukturaObiektowa (Program)
– mo e poda swoje elementy
– mo e zapewni wysokopoziomowy
interfejs umo liwiaj cy odwiedzaj cemu
odwiedzenie elementów
– mo e by wzorcem Composite lub
kolekcj
Współpraca:
• klient musi tworzy obiekt
Odwiedzaj cyKonkretny, a nast pnie przej
struktur obiektow odwiedzaj c ka dy element za
pomoc odwiedzaj cego
• gdy element jest odwiedzany wywołuje operacj
Odwiedzaj cego odpowiedni dla swojej klasy;
dostarcza on siebie samego jako argument tej
operacji, eby umo liwi odwiedzaj cemu dost p
do swojego stanu
strukturaObiektowaA
elementKonkretnyA
elementKonkretnyB
odwiedzaj cyKonkretny
1: Przyjmij(odwiedzaj cy)
2: Odwied ElementKonk ret nyA(elementKonkretnyA)
3: OperacjaA()
4: Przyjmij(odwiedzaj cy)
5: Odwied ElementKonkretnyB(elementKonkretnyB)
6: OperacjaB()
Konsekwencje:
• łatwe dodawanie nowych operacji
• zebranie razem powi zanych ze sob operacji a
rozdzielenie niepowi zanych
• trudne dodawanie nowych klas ElementKonkretny
• odwiedzanie całej hierarchii klas - lepiej ni
iterator, bo mo e działa na ró nych typach
• kumulowanie stanu
• naruszanie kapsułkowania – operacje dost pu do
stanu obiketów klasy ElementKonkretny
Implementacja:
• wywoływanie dwukrotne
• który z uczestników jest odpowiedzialny za
przechodzenie struktury obiektowej?
Przykłady
Zastosowania
Pokrewne wzorce:
• Composite – mo na odwiedza hierarchi
kompozytu
• Interpreter – zastosowanie do
interpretowania