🚀 go-pugleaf

Filip Sielimowicz napisał(a):
> Sprawa wygląda tak: stosujemy wzorzec Observer.
> 
> Obserwowany obiekt to maszyna stanów.
> Obserwator nasłuchuje na zdarzenia zmian stanów maszyny.
> 
> Chciałbym dać obserwatorom możliwość ingerencji
> w zmiany stanów, tj. mogą rzucać wyjątek w rodzaju
> StateUpdateVetoException i maszyna stanów honoruje takie
> wyjątki jako sygnały: nie zmieniać stanu, zostać w starym.
> 
> Czy takie cuś mieści się dalej we wzorcu Observer, czy
> zdecydowanie należy tu szukać już innego wzoca ? Jakiego ?
> 
> 
Mimo iż książka GoF nie podaje takiego przykładu, myślę że blokowanie 
zmiany stanu przez obserwatora jest naturalne,np. zamykanie dokumentu w 
Wordzie z pytaniem czy zapisać.

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Dnia Tue, 31 Jan 2006 14:19:45 +0100, Filip Sielimowicz skrobie:
> Sprawa wygl?da tak: stosujemy wzorzec Observer.

> Obserwowany obiekt to maszyna stanów.
> Obserwator nasłuchuje na zdarzenia zmian stanów maszyny.

> Chciałbym dać obserwatorom możliwo?ć ingerencji
> w zmiany stanów, tj. mog? rzucać wyj?tek w rodzaju
> StateUpdateVetoException i maszyna stanów honoruje takie
> wyj?tki jako sygnały: nie zmieniać stanu, zostać w starym.

> Czy takie cu? mie?ci się dalej we wzorcu Observer, czy
> zdecydowanie należy tu szukać już innego wzoca ? Jakiego ?

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.

(From: http://sern.ucalgary.ca/courses/SENG/609.04/W98/lamsh/observerLib.html)
(From: http://www.google.com/q=observer+pattern kolego!)

Skoro za pomocą widoku można aktualizować model, to znaczy, że Observer może
ingerować w model.



-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

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.

-- 
a1 (Bartek Janusz) arcone1 gmail com

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 

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 ! :)