🚀 go-pugleaf

Filip Sielimowicz wrote:
> 
> 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ę.
> 

Nic dodac nic ujac ! :)