🚀 go-pugleaf

Użytkownik "a1" <a1@no.spam> napisał w wiadomości 
news:drpqhk$2o8$2@inews.gazeta.pl...
> Sektor van Skijlen wrote:
> > Dnia Tue, 31 Jan 2006 14:19:45 +0100, Filip Sielimowicz skrobie:
>
> > Wygląda na to, że można.
> >
> >   Known Uses
> >
> > Smalltalk Model/View/Controller (MVC). User interface framework while
> Model is
> > subject and View is observer.
>
> > Skoro za pomocą widoku można aktualizować model, to znaczy, że
> Observer może
> > ingerować w model.
>
> Tylko ze widok nie powinnien aktualizowac modelu do tego sluzy kontroler.
>
> Do OP
> Np. javie dosyc szeroko sa stosowane VetoableListenery, i mechanizm 
> calkiem dobrze sie sprawdza. W koncu Dessign Patterns to nie biblia i nie 
> jest koniecznym literalne trzymanie sie przedstawionych konceptow.

Ja się właśnie zastanawiam, czy kilku spraw, które dotąd nazywałem
listenerami nie zacząć nazywać observerami (w zasadzie już doszedłem do 
wniosku,
że warto). Listenery nie realizują dokładnie tego, co jest zapisane we 
wzorcu
observer, bo wiele z nich ma np. kilka metod dla różnych zdarzeń zamiast
jednej metody update (np MouseListener, WindowListener). Ale za to wzorzec
jest bardziej zrozumiały i lepiej porządkuje nazewnictwo. Interfejsy 
listenerów
bardzo często mają nazwy pochodne od zdarzeń, które je interesują 
(ActionListener,
PropertyChangeListener), natomiast interfejsy Observerów pozostają albo na 
poziomie
ogólnym (po prostu Observer), albo są pochodną nazwy obserwowanego obiektu
(nie zdarzeń). Zaś dopiero specyficzne implementacje nazwami wchodzą w 
szczegóły
zastosowań i np. eksponują co dokładnie w obserwowanym obiekcie je 
interesuje.
Można np. zobaczyć to tu:
http://www.javaworld.com/javaworld/javatips/jw-javatip29.html

Takie podejście np. w moim wypadku skłoniło mnie do tego, by mnożące
się interfejsy listenerów jakiegoś wyjątkowo interesujacego, wiecznie 
aktywnego
obiektu (u mnie to maszyna stanów, która poza stanami ma jeszcze kilka 
innych rzeczy,
np. cykl życia z następujacymi po sobie fazami, wywołuje funkcje biznesowe, 
w ramach
których są otwierane i zamykane transakcje itp) schować za jednym zwartym 
interfejsem
Observera z licznymi metodami odpowiadajacymi zmianom stanów, zmianom faz 
życia,
zmianom stanów transakcji bd itp).

Ma to tę zaletę, że rzadko kto obserwujacy taki złożony obiekt jest 
nastawiony
na nasłuch tylko jednego zdarzenia - zazwyczaj interesuje go ich kilka. 
Zamiast
wiec implementować wiele listenerów implementujemy jeden interfejs 
observera.
Zmiana właściwie jest kosmetyczna - ale dużo bardziej zwarta na diagramach 
np.
diagramach klas, gdzie mamy jeden observer z metodami zamiast kilku 
listenerów.
Na takim diagramie od razu widać zastosowanie konkretnego wzorca 
projektowego
bez konieczności wprowadzania dodatkowego opisu typu "ten interfejs i ten i 
ten
są observerami, a tamten już coś innego".

Ma to wadę wydajnościową, ale kwestię pominę.

-- 
Filip Sielimowicz