🚀 go-pugleaf

Dnia Mon, 10 Jul 2006 21:22:01 +0200, Przemek Pokrywka skrobie:
> Witam Państwa!

> W praktyce często mam do czynienia z następującą sytuacją:
> pojedynczy obiekt (nazwę go manager) jest centralnym punktem dostępu do 
> wielu obiektów jednego typu (dzieci). Cykl życiowy tych obiektów jest 
> taki, że manager rozpoczyna życie przed dziećmi, które kończą swoje 
> życia przed końcem życia managera. Manager umożliwia odnajdywanie swoich 
> dzieci wg określonych kryteriów oraz tworzenie ich.

> Jak na razie wszystko jest ok, ale zaskakująco często widuję 
> towarzyszącą temu wzorcowi praktykę, która już nie jest dla mnie taka ok.

> Mianowicie bardzo często obiekt managera poza udostępnianiem metod, 
> które logicznie nie pasują do dzieci, jak np. wyszukiwanie zawiera 
> metody służące do operowania na pojedynczych dzieciach.

> Np.
> SessionManager udostępnia metodę

>         void setDeactivated(Session s)

> której cała implementacja to:

>         s.setDeactivated();

> Czy nie byłoby lepiej, gdyby to użytkownik operował bezpośrednio na 
> Session? Przedstawiony schemat, który często napotykam, pachnie mi 
> antywzorcem Man-In-The-Middle.

To zależy. W przypadku Javy pewnie tak (bo nie da się zabronić dostępu do
zewnętrznie zdefiniowanej klasy). W przypadku C++ nie jest to już takie
oczywiste, bo można zrobić klasę taką, do której metod (w tym konstruktora) ma
dostęp tylko inna (wskazana) klasa. W takim przypadku ktoś "z zewnątrz" mógłby
wszelkie operacje wykonać tylko za pośrednictwem managera.

Można też stosować taką technikę, że to, co podajesz do metody managera (tu
podajesz Session), nie będzie bezpośrednim wskazaniem na obiekt, tylko jego
identyfikatorem. Czyli z zewnątrz można tylko menedżerowi powiedzieć, o jaki
obiekt nam chodzi, ale nie można na nim samodzielnie wykonywać żadnych
operacji.

Przykład z twojej strony nie ma za wiele sensu, bo problem nie polega na
sposobie zaimplementowania całego mechanizmu, lecz na logice całego "designu".
Rozstrząsanie, czy setDeactivated powinno być metodą managera, jest zupełnie
bezprzedmiotowe - zapytaj raczej, dlaczego ktoś z zewnątrz miałby mieć
możliwość deaktywacji sesji, po co mu to, a w związku z tym, czy sposób
operowania menedżerem, jaki opracowałeś, tworząc jego interfejs, przewiduje
deaktywację sesji z zewnątrz, czy nie.

Jeśli implementacja polega na przekierowaniu do metody sesji, to być może i
nie ma to za wiele sensu. Ale jeśli obiekt sesji dostaje poza tym kopa ze
zbiornika sesji, to już nie wydaje się być to takie bez sensu.

> Wydaje mi się, że jeśli nawet taki manager chce koniecznie kontrolować 
> zmiany w swoich dzieciach, to lepszy do tego jest wzorzec Observer, 

Observer? Z choinki się urwałeś? To jest zupełnie inny temat, inna kategoria.
Kto miałby być observerem kogo i - przede wszystkim - jakie stany cząstkowe
danego obiektu miałyby być "obserwowane" przez obserwatorów? Spróbuj
odpowiedzieć na powyższe pytanie, to będziesz wiedział, czy Observer się
nadaje. Hint:

http://sern.ucalgary.ca/courses/SENG/609.04/W98/lamsh/observerLib.html


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

Przemek Pokrywka napisał(a):
> Witam Państwa!
>
> W praktyce często mam do czynienia z następującą sytuacją:
> pojedynczy obiekt (nazwę go manager) jest centralnym punktem dostępu do
> wielu obiektów jednego typu (dzieci). Cykl życiowy tych obiektów jest
> taki, że manager rozpoczyna życie przed dziećmi, które kończą swoje
> życia przed końcem życia managera. Manager umożliwia odnajdywanie swoich
> dzieci wg określonych kryteriów oraz tworzenie ich.
>
> Jak na razie wszystko jest ok, ale zaskakująco często widuję
> towarzyszącą temu wzorcowi praktykę, która już nie jest dla mnie taka ok.
>
> Mianowicie bardzo często obiekt managera poza udostępnianiem metod,
> które logicznie nie pasują do dzieci, jak np. wyszukiwanie zawiera
> metody służące do operowania na pojedynczych dzieciach.
>
> Np.
> SessionManager udostępnia metodę
>
> 	void setDeactivated(Session s)
>
> której cała implementacja to:
>
> 	s.setDeactivated();
>
> Czy nie byłoby lepiej, gdyby to użytkownik operował bezpośrednio na
> Session? Przedstawiony schemat, który często napotykam, pachnie mi
> antywzorcem Man-In-The-Middle.
>
> Wydaje mi się, że jeśli nawet taki manager chce koniecznie kontrolować
> zmiany w swoich dzieciach, to lepszy do tego jest wzorzec Observer,
> zgodzą się ze mną Państwo?

Zgadzam sie.

W poprzednim projekcie spotykalem bardzo czesto taki schemat.
Poczatkowo operowalismy bezposrednio na obiektach-dzieciach.
Pozniej zwykle okazywalo sie, ze potrzebne jest wyslanie powiadomienia
do zainteresowanych obiektow w zwiazku z wykonywana operacja na
obiekcie-dziecku.
Korzystalismy wtedy z wzorca Observer (Manager byl obiektem
obserwowanym).

W koncu zrezygnowalismy z bezposredniego operowania na
obiektach-dzieciach i wszystkie akcje zmieniajace stan takiego
obiektu-dziecka byly zawsze kontrolowane przez jego managera
(obserwowanego).

D.

"Darek Kubiczek" <darek_kubiczek@wp.pl> wrote in message

>> Wydaje mi się, że jeśli nawet taki manager chce koniecznie kontrolować
>> zmiany w swoich dzieciach, to lepszy do tego jest wzorzec Observer,
>> zgodzą się ze mną Państwo?

> Zgadzam sie.
>W poprzednim projekcie spotykalem bardzo czesto taki schemat.
>Poczatkowo operowalismy bezposrednio na obiektach-dzieciach.
>Pozniej zwykle okazywalo sie, ze potrzebne jest wyslanie powiadomienia
>do zainteresowanych obiektow w zwiazku z wykonywana operacja na
>obiekcie-dziecku.
>Korzystalismy wtedy z wzorca Observer (Manager byl obiektem
>obserwowanym).

A nie powinno byz tak ze wlasnie Manager powinien byc obserwatorem
a obiekty obserwowanymi przez ten obserwator ?

Chyba to mial na mysli Przemek Pokrywka ?

>W koncu zrezygnowalismy z bezposredniego operowania na
>obiektach-dzieciach i wszystkie akcje zmieniajace stan takiego
>obiektu-dziecka byly zawsze kontrolowane przez jego managera
>(obserwowanego).

IMHO to juz mi sie bardzo nie podoba.
Uzasadnienie: zwyciestwo technikaliow nad rzeczywistoscia.

PS: Nie jestem zawodowym projektantem a jedynie programista wiec
        moge sie mylic ;)

AK 

Dnia Tue, 11 Jul 2006 12:35:43 +0200, Adam Karpierz skrobie:
> "Darek Kubiczek" <darek_kubiczek@wp.pl> wrote in message

> >> Wydaje mi się, że je?li nawet taki manager chce koniecznie kontrolować
> >> zmiany w swoich dzieciach, to lepszy do tego jest wzorzec Observer,
> >> zgodz? się ze mn? Państwo?

> > Zgadzam sie.
> >W poprzednim projekcie spotykalem bardzo czesto taki schemat.
> >Poczatkowo operowalismy bezposrednio na obiektach-dzieciach.
> >Pozniej zwykle okazywalo sie, ze potrzebne jest wyslanie powiadomienia
> >do zainteresowanych obiektow w zwiazku z wykonywana operacja na
> >obiekcie-dziecku.
> >Korzystalismy wtedy z wzorca Observer (Manager byl obiektem
> >obserwowanym).

> A nie powinno byz tak ze wlasnie Manager powinien byc obserwatorem
> a obiekty obserwowanymi przez ten obserwator ?

> Chyba to mial na mysli Przemek Pokrywka ?

No właśnie to chyba miał na myśli i właśnie dlatego to jest bez sensu.

Wzorzec obserwatora polega (podobno) na tym, że obiekty obserwujące
synchronizują swój stan z obiektem obserwowanym w przypadku zmiany stanu
obiektu obserwowanego. Do przedstawionego przypadku ma się to jak balon do
kaktusa: przedstawiona operacja jest wykonywana na określonej, wskazanej sesji
i specjalnie dla niej. Obserwator zaciera fakt istnienia obserwacji; obiekt
obserwowany (teoretycznie) nie wie o tym, że jest obserwowany.

> >W koncu zrezygnowalismy z bezposredniego operowania na
> >obiektach-dzieciach i wszystkie akcje zmieniajace stan takiego
> >obiektu-dziecka byly zawsze kontrolowane przez jego managera
> >(obserwowanego).

> IMHO to juz mi sie bardzo nie podoba.
> Uzasadnienie: zwyciestwo technikaliow nad rzeczywistoscia.

Co więcej, to brzmi już całkiem bez sensu, bo do zmian stanu określonego
obiektu powinny służyć jego metody. Można jedynie decydować, czy się chce
dopuszczać metody z zewnątrz do metod tych obiektów, czy też dopuszcza się to
tylko do ich menedżera, ale o tym już pisałem.

> PS: Nie jestem zawodowym projektantem a jedynie programista wiec
>         moge sie mylic ;)

Taaa... o "projektantach" już było na stronie www.waterfall2006.com.

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

Adam Karpierz napisał(a):
> "Darek Kubiczek" <darek_kubiczek@wp.pl> wrote in message
>
> >> Wydaje mi się, że jeśli nawet taki manager chce koniecznie kontrolować
> >> zmiany w swoich dzieciach, to lepszy do tego jest wzorzec Observer,
> >> zgodzą się ze mną Państwo?
>
> > Zgadzam sie.
> >W poprzednim projekcie spotykalem bardzo czesto taki schemat.
> >Poczatkowo operowalismy bezposrednio na obiektach-dzieciach.
> >Pozniej zwykle okazywalo sie, ze potrzebne jest wyslanie powiadomienia
> >do zainteresowanych obiektow w zwiazku z wykonywana operacja na
> >obiekcie-dziecku.
> >Korzystalismy wtedy z wzorca Observer (Manager byl obiektem
> >obserwowanym).
>
> A nie powinno byz tak ze wlasnie Manager powinien byc obserwatorem
> a obiekty obserwowanymi przez ten obserwator ?
>
> Chyba to mial na mysli Przemek Pokrywka ?

Hmm, wyglada na to ze chyba nie zrozumialem Przemka.
Mi chodzilo o wykorzystanie wzorca Observer nastepujaco: Manager
(obserwowany) i klienci Managera (obserwatorzy).
Podejscie w ktorym Manager obserwuje swoje obiekty-dzieci wydaje mi sie
dziwne.

> >W koncu zrezygnowalismy z bezposredniego operowania na
> >obiektach-dzieciach i wszystkie akcje zmieniajace stan takiego
> >obiektu-dziecka byly zawsze kontrolowane przez jego managera
> >(obserwowanego).
>
> IMHO to juz mi sie bardzo nie podoba.
> Uzasadnienie: zwyciestwo technikaliow nad rzeczywistoscia.

Roznica z punktu widzenia programisty uzywajacego tego rozwiazania jest
taka ze zamiast:

session.setDeactivated ();

musialby napisac:

sesssionManager.setDeactivated ( session );

A to chyba nie jest specjalnie duzy problem ?

D.

Dnia 11 Jul 2006 04:46:35 -0700, Darek Kubiczek skrobie:
> Mi chodzilo o wykorzystanie wzorca Observer nastepujaco: Manager
> (obserwowany) i klienci Managera (obserwatorzy).

Zgoda, tylko że akurat nazwanie tej relacji manager-klient jest zupełnie
niefortunne. Manager, skoro ma czymś zarządzać, to decyduje o, powiedzmy,
ewentualnych zmianach. Tymczasem w przypadku obiektów obserwowanych one niczym
nie zarządzają - ich funkcjonowanie powinno być z założenia niezależne, a
czynności podejmowane w ramach obserwacji jedynie "efektem ubocznym" (co
więcej, w punktach synchronizacji nie następuje zmiana stanu obiektu
obserwowanego!).

> Podejscie w ktorym Manager obserwuje swoje obiekty-dzieci wydaje mi sie
> dziwne.

No właśnie.

> > >W koncu zrezygnowalismy z bezposredniego operowania na
> > >obiektach-dzieciach i wszystkie akcje zmieniajace stan takiego
> > >obiektu-dziecka byly zawsze kontrolowane przez jego managera
> > >(obserwowanego).
> >
> > IMHO to juz mi sie bardzo nie podoba.
> > Uzasadnienie: zwyciestwo technikaliow nad rzeczywistoscia.

> Roznica z punktu widzenia programisty uzywajacego tego rozwiazania jest
> taka ze zamiast:

> session.setDeactivated ();

> musialby napisac:

> sesssionManager.setDeactivated ( session );

> A to chyba nie jest specjalnie duzy problem ?

Nie o to chodzi, czy to jest duży problem, tylko o to, czy wywołanie metody na
rzecz managera (zamiast zainteresowanego obiektu) jest rzeczywiście tożsame z
wywołaniem metody zainteresowanego obiektu. Jeśli jest, manager faktycznie w
tej operacji żadnego udziału nie bierze i jest na kij komu potrzebny. Taka
metoda zatem nie jest faktycznie metodą managera (to tylko taki potworek
techniczny).


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

"Darek Kubiczek" <darek_kubiczek@wp.pl> wrote in message

> Hmm, wyglada na to ze chyba nie zrozumialem Przemka.
> Mi chodzilo o wykorzystanie wzorca Observer nastepujaco: Manager
> (obserwowany) i klienci Managera (obserwatorzy).
> Podejscie w ktorym Manager obserwuje swoje obiekty-dzieci wydaje mi sie
> dziwne.

Dlaczego ?.
Przeciez to jest jak najbardziej naturalne i rzeczywiste.
Pracodawca (manager) obserwuje swoich p[racownikow mimo ze oni
o tym nei musza (a nawet nei powinni) wiedziec.
Pracownik ma jedynei obowiazek "notyfikowac" o tym co robi
(odbic karte, wypelnic wnuiossek urlopowy itp).

Manager to ktois kto chce meic informacje o tym czyms zarzadza
czylki to wlasnei on obserwuje zmainy obiektow obserwowanych.
Obiekty obserwowane nie powinny miec _zadnej_ informacji o tym
czy ktos je  obserwuje czy nie i kto to jest itp.
One jedynie powinny informowac (notyfikacje) o swoich zmianach.
Informowac w ogole. Nie kogos konkretnego.

> >W koncu zrezygnowalismy z bezposredniego operowania na
> >obiektach-dzieciach i wszystkie akcje zmieniajace stan takiego
> >obiektu-dziecka byly zawsze kontrolowane przez jego managera
> >(obserwowanego).
>
> IMHO to juz mi sie bardzo nie podoba.
> Uzasadnienie: zwyciestwo technikaliow nad rzeczywistoscia.

> Roznica z punktu widzenia programisty uzywajacego tego rozwiazania
> jest taka ze zamiast:
>
>session.setDeactivated ();
>
>musialby napisac:
>
>sesssionManager.setDeactivated ( session );
>
>A to chyba nie jest specjalnie duzy problem ?

Dla mnie jest to problem zasadniczy.
To wlasnie typowe "zwyciestwo" technikaliow nad logika.

PS: Wiem.. nei zawsze sie da.. Np gdy Session juz nie mozna tknac
        w sensie interface.
       Ale to nie przeczy temu "zwyciestwu". Tylko je potwierdza.

AK

Dnia Tue, 11 Jul 2006 16:05:52 +0200, Adam Karpierz skrobie:
> "Darek Kubiczek" <darek_kubiczek@wp.pl> wrote in message

> > Hmm, wyglada na to ze chyba nie zrozumialem Przemka.
> > Mi chodzilo o wykorzystanie wzorca Observer nastepujaco: Manager
> > (obserwowany) i klienci Managera (obserwatorzy).
> > Podejscie w ktorym Manager obserwuje swoje obiekty-dzieci wydaje mi sie
> > dziwne.

> Dlaczego ?.
> Przeciez to jest jak najbardziej naturalne i rzeczywiste.
> Pracodawca (manager) obserwuje swoich p[racownikow mimo ze oni
> o tym nei musza (a nawet nei powinni) wiedziec.
> Pracownik ma jedynei obowiazek "notyfikowac" o tym co robi
> (odbic karte, wypelnic wnuiossek urlopowy itp).

Generalnie masz rację, ale po prostu nie na tym polega wzorzec Observer.

Rozważanie tego typu powinno przede wszystkim uwzględnić fakt istnienia stanów
(cząstkowych zresztą), ich zmienności i to właśnie te zmiany podlegają
obserwacji. Jeśli ktoś chce obserwować, to musi wiedzieć co i u kogo ma zamiar
obserwować. W przypadku wzorca Observer chodzi o zmienności, które mogą być
obserwowane przez dowolny obiekt, przy czym stany cząstkowe obiektu
obserwowanego cechuje duża zmienność i jest on wręcz takim "kontrolerem
zmian". Natomiast obiekty obserwujące obserwują tylko niektóre z tych zmian,
te, które je akurat interesują.

W tym, co przedstawiłeś, wygląda to zupełnie inaczej. Tam masz wiele obiektów,
które chciałbyś obserwować, wszystkie są do siebie podobne (tylko podobne!) i
ich zmienności są niemal identyczne. Poza tym obiekt nadzorczy nie musi na
bieżąco obserwować tego, co robi obiekt podległy - to nie ludzie, że trzeba im
ciągle patrzeć na ręce, czy pracują :). Obiekt nadzorujący jest zainteresowany
co najwyżej raportami z prac - a to robi się zupełnie inaczej: pracownik wie,
że ma wysłać raport do nadzorcy i wysyła go, gdy wykona przykazaną czynność,
względnie raportuje "progress", jeśli tak został zaprogramowany.

Generalnie różnica opiera się na tym, że w przypadku wzorca observer,
obserwowany obiekt nie tylko nie musi wiedzieć o tym, że jest obserwowany, ale
nie musi w ogóle wiedzieć, że istnieje obiekt obserwujący. Tak nie jest w
przypadku relacji manager-pracownik, bo nie bardzo sobie wyobrażam sytuację, w
której pracownik w ogóle nie wie, czy ma jakiegoś managera (patologie pomińmy
:).

> Manager to ktois kto chce meic informacje o tym czyms zarzadza
> czylki to wlasnei on obserwuje zmainy obiektow obserwowanych.
> Obiekty obserwowane nie powinny miec _zadnej_ informacji o tym
> czy ktos je  obserwuje czy nie i kto to jest itp.
> One jedynie powinny informowac (notyfikacje) o swoich zmianach.
> Informowac w ogole. Nie kogos konkretnego.

I tu tkwi właśnie błąd.

Po pierwsze, pracownik dostaje zlecenia wykonania zadań właśnie od managera i
jemu raportuje. Niewidzialność zatem jeśli nawet zostanie zorganizowana, jest
wyłącznie sztuczna. Po drugie, jeśli manager jest tylko obserwatorem, to w
takim razie jego pracę powinien móc obserwować każdy. Jeśli więc obserwację
połączysz z zarządzaniem, to możesz sobie wyobrazić, co się stanie, jeśli
takim obiektem będzie mógł również każdy zarządzać.

Relacja manager-klient powinna się zatem wiązać z wykonywaniem transakcji, a
nie rozgłaszania, które zakłada wzorzec observer.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ 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" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
wrote:

>> Dlaczego ?.
>> Przeciez to jest jak najbardziej naturalne i rzeczywiste.
>> Pracodawca (manager) obserwuje swoich p[racownikow mimo ze oni
>> o tym nei musza (a nawet nei powinni) wiedziec.
>> Pracownik ma jedynei obowiazek "notyfikowac" o tym co robi
>> (odbic karte, wypelnic wnuiossek urlopowy itp).
>
> Generalnie masz rację, ale po prostu nie na tym polega wzorzec Observer.

A co mnie tam obchodzi w tym momencie wzorzec Observer ?

Probuje od samego poczatku oderwac sie od "wzorcomanii" i
sprobowac ukonkretnic model/schemat w/g ktorego IMHO
powinna dzialac w/w zaleznosc manager obiektow/obiekty.

To czy bedzie to pasowac akurat do wzorca observer czy innego
_w ogole_ mnie nie na tym etapie nie interesuje.
Uwazam nawet ze jest to w tym momencie szkodliwe.
Zainteresuje (i to tylko ewentualnie, gdy bedzie "pasowalo" w blisko100%
do ktoregos z wzorcow) na samym koncu modelowania.
Wtedy sobie ew. moge dopisac laurke (dla marketinguchyba:)
 ze to dziala w/g wzorca Observer, Visitor , Mediator czy jakiegos
innego (nie znam sie).
Jesli sobie takiego wzorca nie dopasuje to sobie napisze ze to jest
"wzorzec wlasny", a _nigdy_ nie bede dzialania/modelu naginal pod
konkretny wzorzec tylko dla latki "zrobione w/g wzorca XXX".

Stad moje slowa o tym ze "zwyciestwie" technikaliow nad rzeczywistoscia.

AK

Adam Karpierz napisał(a):
> "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
> wrote:
> 
> 
>>>Dlaczego ?.
>>>Przeciez to jest jak najbardziej naturalne i rzeczywiste.
>>>Pracodawca (manager) obserwuje swoich p[racownikow mimo ze oni
>>>o tym nei musza (a nawet nei powinni) wiedziec.
>>>Pracownik ma jedynei obowiazek "notyfikowac" o tym co robi
>>>(odbic karte, wypelnic wnuiossek urlopowy itp).
>>
>>Generalnie masz rację, ale po prostu nie na tym polega wzorzec Observer.
> 
> 
> A co mnie tam obchodzi w tym momencie wzorzec Observer ?
> 
> Probuje od samego poczatku oderwac sie od "wzorcomanii" i
> sprobowac ukonkretnic model/schemat w/g ktorego IMHO
> powinna dzialac w/w zaleznosc manager obiektow/obiekty.
> 
> To czy bedzie to pasowac akurat do wzorca observer czy innego
> _w ogole_ mnie nie na tym etapie nie interesuje.
> Uwazam nawet ze jest to w tym momencie szkodliwe.
> Zainteresuje (i to tylko ewentualnie, gdy bedzie "pasowalo" w blisko100%
> do ktoregos z wzorcow) na samym koncu modelowania.
> Wtedy sobie ew. moge dopisac laurke (dla marketinguchyba:)
>  ze to dziala w/g wzorca Observer, Visitor , Mediator czy jakiegos
> innego (nie znam sie).
> Jesli sobie takiego wzorca nie dopasuje to sobie napisze ze to jest
> "wzorzec wlasny", a _nigdy_ nie bede dzialania/modelu naginal pod
> konkretny wzorzec tylko dla latki "zrobione w/g wzorca XXX".
> 
> Stad moje slowa o tym ze "zwyciestwie" technikaliow nad rzeczywistoscia.
> 
> AK
> 
> 


Adamie (jeśli mogę na "Ty"), poprawnie rozszyfrowałeś moje intencje 
jeśli chodzi o Observera :)

Przyznam, że szczerze mnie rozbawiła myśl o naginaniu modelu pod 
konkretny wzorzec. Oczyma mojej wyobraźni widzę już Pana Projektanta 
(ba! Architekta) zastanawiającego się, którego wzorca w danym przypadku 
użyć (i, zniecierpliwionego brakiem natchnienia, wertującego spis treści 
GoF). ROTFL :-))))

Ludzie (a zwłaszcza Ty, Sektorze) - czy od czasu GoF nie pojawiają się 
już nowe wzorce projektowe? Spójrzcie sobie chociaż na twórczość Roberta 
C. Martina, ile on natworzył odmian wzorca Visitor.

Pisząc "Observer" miałem jedynie na myśli pewną klasę wzorców, a nie 
literalne zastosowanie wzorca wg tekstu GoF. Z takim zresztą 
traktowaniem wzorców (jako środka wspomagającego komunikację) spotykam 
się na każdym kroku w sieci. Nie jestem na tej grupie osamotniony, bo 
Adam od razu zorientował się, o co mi chodzi.
A widziałem już sporo odmian każdego ze wzorców, żeby zrozumieć co jest 
w nich niezmienne i naprawdę ważne.

Jasne, możliwość zastosowania wzorca w jego najbardziej standardowej 
postaci jest najlepsza, bo można ją np. szybciej zakomunikować nowemu 
uczestnikowi projektu, ale modelowana rzeczywistość bywa różna i na 
pewno nie należy jej naginać na potrzebę zastosowania jakiegokolwiek 
wzorca! W innym przypadku możemy się rozminąć z radą A. Einsteina 
"Everything should be as simple as possible - but __no__ simpler", wraz 
ze wszystkimi tego konsekwencjami.

W użytym przeze mnie przykładzie SessionManager po otrzymaniu informacji 
od Session, że została zdeaktywowana aktualizował jeden ze swoich 
wewnętrznych indeksów, służących mu do wyszukiwania sesji aktywnych.

Życząc wszystkim miłego wieczoru
Przemek Pokrywka

On Tue, 11 Jul 2006 19:07:17 +0200, "Adam Karpierz"
<karpierz@NOOOOSPAAAAMpython.pl> wrote:

>"Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
>wrote:
>
>>> Dlaczego ?.
>>> Przeciez to jest jak najbardziej naturalne i rzeczywiste.
>>> Pracodawca (manager) obserwuje swoich p[racownikow mimo ze oni
>>> o tym nei musza (a nawet nei powinni) wiedziec.
>>> Pracownik ma jedynei obowiazek "notyfikowac" o tym co robi
>>> (odbic karte, wypelnic wnuiossek urlopowy itp).
>>
>> Generalnie masz rację, ale po prostu nie na tym polega wzorzec Observer.
>
>A co mnie tam obchodzi w tym momencie wzorzec Observer ?
>
>Probuje od samego poczatku oderwac sie od "wzorcomanii" i
>sprobowac ukonkretnic model/schemat w/g ktorego IMHO
>powinna dzialac w/w zaleznosc manager obiektow/obiekty.
>
>To czy bedzie to pasowac akurat do wzorca observer czy innego
>_w ogole_ mnie nie na tym etapie nie interesuje.
>Uwazam nawet ze jest to w tym momencie szkodliwe.
>Zainteresuje (i to tylko ewentualnie, gdy bedzie "pasowalo" w blisko100%
>do ktoregos z wzorcow) na samym koncu modelowania.
>Wtedy sobie ew. moge dopisac laurke (dla marketinguchyba:)
> ze to dziala w/g wzorca Observer, Visitor , Mediator czy jakiegos
>innego (nie znam sie).
>Jesli sobie takiego wzorca nie dopasuje to sobie napisze ze to jest
>"wzorzec wlasny", a _nigdy_ nie bede dzialania/modelu naginal pod
>konkretny wzorzec tylko dla latki "zrobione w/g wzorca XXX".
>
>Stad moje slowa o tym ze "zwyciestwie" technikaliow nad rzeczywistoscia.

Slusznie. Jak mawial Kadet Pirx: "schodki w rakietach sa dla
umierajacych astronautow". W dyskusjach "patternowych" srodki
pzreslaniaja cel. Na ogol zapomina sie "po co i dlaczego" a patrzy
sie czy projekt ejst zgodny z podrecznikiem. Co na ogol wystepuje
jak astronauci sa umierajacy. Albo niedouczeni. 

A.L.

A.L. <alewando@fala2005.com> napisal:
> Slusznie. Jak mawial Kadet Pirx: "schodki w rakietach sa dla
> umierajacych astronautow". W dyskusjach "patternowych" srodki

To byl "Osla Laczka" - wykladowca Pirxa. Ale to tylko tak
na marginesie.
-- 
Pozdrawiam,

Jacek

Dnia Tue, 11 Jul 2006 19:07:17 +0200, Adam Karpierz skrobie:
> "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
> wrote:

> >> Dlaczego ?.
> >> Przeciez to jest jak najbardziej naturalne i rzeczywiste.
> >> Pracodawca (manager) obserwuje swoich p[racownikow mimo ze oni
> >> o tym nei musza (a nawet nei powinni) wiedziec.
> >> Pracownik ma jedynei obowiazek "notyfikowac" o tym co robi
> >> (odbic karte, wypelnic wnuiossek urlopowy itp).
> >
> > Generalnie masz rację, ale po prostu nie na tym polega wzorzec Observer.

> A co mnie tam obchodzi w tym momencie wzorzec Observer ?

Może cię nie obchodzić, ale w pierwotnym mailu było pytanie o to, czy w danym
przypadku należy stosować wzorzec Observer. Możemy podyskutować nad kwestią
obserwacji i sposobem najlepszego rozwiązania tego problemu, ale nie mówmy
wtedy o wzorcu Observer.

> Probuje od samego poczatku oderwac sie od "wzorcomanii" i
> sprobowac ukonkretnic model/schemat w/g ktorego IMHO
> powinna dzialac w/w zaleznosc manager obiektow/obiekty.

Bardzo dobrze.

> To czy bedzie to pasowac akurat do wzorca observer czy innego
> _w ogole_ mnie nie na tym etapie nie interesuje.
> Uwazam nawet ze jest to w tym momencie szkodliwe.
> Zainteresuje (i to tylko ewentualnie, gdy bedzie "pasowalo" w blisko100%
> do ktoregos z wzorcow) na samym koncu modelowania.
> Wtedy sobie ew. moge dopisac laurke (dla marketinguchyba:)
>  ze to dziala w/g wzorca Observer, Visitor , Mediator czy jakiegos
> innego (nie znam sie).
> Jesli sobie takiego wzorca nie dopasuje to sobie napisze ze to jest
> "wzorzec wlasny", a _nigdy_ nie bede dzialania/modelu naginal pod
> konkretny wzorzec tylko dla latki "zrobione w/g wzorca XXX".

> Stad moje slowa o tym ze "zwyciestwie" technikaliow nad rzeczywistoscia.

Całkiem słusznie.

Wzorce nie są złe, ale - jak wszystkie "narzędzia", "automatyzacje",
"ułatwiacze" itp. - pod warunkiem, że wzorce są dla nas pomocą i podpowiedzią,
dobrą, sprawdzoną metodą, której zastosowanie można rozważyć, natomiast nie
wyrocznią. Ktoś, kto by np. twierdził, że do każdego rozwiązania można
wyznaczyć odpowiedni wzorzec (lub zastanawia się, z jakiego wzorca skorzystać
dla rozwiązania danego problemu) nie znajdzie nigdy dobrego rozwiązania.


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

Dnia Tue, 11 Jul 2006 21:07:30 +0200, Przemek Pokrywka skrobie:
> Przyznam, że szczerze mnie rozbawiła myśl o naginaniu modelu pod 
> konkretny wzorzec. Oczyma mojej wyobraźni widzę już Pana Projektanta 
> (ba! Architekta) zastanawiającego się, którego wzorca w danym przypadku 
> użyć (i, zniecierpliwionego brakiem natchnienia, wertującego spis treści 
> GoF). ROTFL :-))))

Właśnie o tym samym pomyślałem i też mnie to rozbawiło ;).

> Ludzie (a zwłaszcza Ty, Sektorze) - czy od czasu GoF nie pojawiają się 
> już nowe wzorce projektowe? Spójrzcie sobie chociaż na twórczość Roberta 
> C. Martina, ile on natworzył odmian wzorca Visitor.

No dobrze, ale jeśli już się zabieramy za tworzenie odmian, to trzeba
wiedzieć nie tylko, czy dany wzorzec można tu zastosować, ale czy w ogóle
opłaca się wymyślać odmianę jakiegoś konkretnego wzorca. Cała idea Observera
zasadza się nie na delegowaniu operacji (bo to ci jest właśnie tu potrzebne),
tylko na synchronizacji stanu. Dlatego moim zdaniem z wzorca Observer jedyne,
co ci jest tu potrzebne, to hipotetyczne "obserwowanie". Co i tak nie jest
jeszcze dokładnie tym, co ci jest potrzebne.

> Pisząc "Observer" miałem jedynie na myśli pewną klasę wzorców, a nie 
> literalne zastosowanie wzorca wg tekstu GoF. Z takim zresztą 
> traktowaniem wzorców (jako środka wspomagającego komunikację) spotykam 
> się na każdym kroku w sieci. Nie jestem na tej grupie osamotniony, bo 
> Adam od razu zorientował się, o co mi chodzi.
> A widziałem już sporo odmian każdego ze wzorców, żeby zrozumieć co jest 
> w nich niezmienne i naprawdę ważne.

To, co jest w tych wzorcach istotne, to ich idee i podstawowe założenia. Jeśli
to, co chcesz zrobić, sprzecza się z tymi założeniami, to wzorca nie możesz
nie tylko zastosować, ani nawet przykroić. Jeśli nawet chcesz stworzyć odmianę
wzorca, to musisz zdawać sobię sprawę z jego podstawowych założeń i działać
dokładnie z tymi założeniami. Jeśli się nie da, to po cholere się pchać w
konkretny wzorzec - wymyślić po prostu swoje własne, dobre rozwiązanie. Wzorce
mogą służyć jako podpowiedź lub podsuwanie dobrych (sprawdzonych) pomysłów, a
nie gotowych rozwiązań.

> Jasne, możliwość zastosowania wzorca w jego najbardziej standardowej 
> postaci jest najlepsza, bo można ją np. szybciej zakomunikować nowemu 
> uczestnikowi projektu, ale modelowana rzeczywistość bywa różna i na 
> pewno nie należy jej naginać na potrzebę zastosowania jakiegokolwiek 
> wzorca!

Dokładnie tak.

> W innym przypadku możemy się rozminąć z radą A. Einsteina 
> "Everything should be as simple as possible - but __no__ simpler", wraz 
> ze wszystkimi tego konsekwencjami.

> W użytym przeze mnie przykładzie SessionManager po otrzymaniu informacji 
> od Session, że została zdeaktywowana aktualizował jeden ze swoich 
> wewnętrznych indeksów, służących mu do wyszukiwania sesji aktywnych.

No właśnie to miałem na myśli, mówiąc że sesja miałaby być przez managera
jeszcze dodatkowo "wykopana" ze zbiornika.

I właśnie dlatego sesja nie powinna być dostępna z zewnątrz, bo deaktywacja
sesji z zewnątrz spowodowałaby pozostawienie "zwłok" w manadżerze.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ 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" <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote 
in message

> No dobrze, ale jeśli już się zabieramy za tworzenie odmian, to trzeba
> wiedzieć nie tylko, czy dany wzorzec można tu zastosować, ale czy w ogóle
> opłaca się wymyślać odmianę jakiegoś konkretnego wzorca. Cała idea 
> Observera
> zasadza się nie na delegowaniu operacji (bo to ci jest właśnie tu 
> potrzebne),
> tylko na synchronizacji stanu.

Wlasnie dokladnie _nie jest_ to tutaj potrzebne
Wcale nie chodzi o delegowanie operacji.
Delegacja operacji jest tutaj zbedna, a nawet szkodliwa bo sugeruje
ze to manager odbija karte pracy pracownika, a nei sam pracownik.

Cala idea observera opiera sie na dwoch bardzo prostych zasadach.
1. Obserwator jest w stanie otrzymac informacje o dzialaniach/dzialaniu
    wykonywanym przez obserwowanego.
2. Obserwowany potrafi informowac "wszechswiat" o swoich
     dzialaniach.

To jest clue "wzorca" Observer.
Wszelkie inne to tylko uszczegolowienia/przykrojenia/szczegolne przypadki/
technikalia itp.

AK

On Tue, 11 Jul 2006 22:59:19 +0000 (UTC), Jacek Pietraszek
<pmpietra@kinga.cyf-kr.edu.pl> wrote:

>A.L. <alewando@fala2005.com> napisal:
>> Slusznie. Jak mawial Kadet Pirx: "schodki w rakietach sa dla
>> umierajacych astronautow". W dyskusjach "patternowych" srodki
>
>To byl "Osla Laczka" - wykladowca Pirxa. Ale to tylko tak
>na marginesie.

Rzeczywiscie. Pamiec nie dopisuje...

A.L.

Adam Karpierz napisał(a):
> "Darek Kubiczek" <darek_kubiczek@wp.pl> wrote in message
>
> > Hmm, wyglada na to ze chyba nie zrozumialem Przemka.
> > Mi chodzilo o wykorzystanie wzorca Observer nastepujaco: Manager
> > (obserwowany) i klienci Managera (obserwatorzy).
> > Podejscie w ktorym Manager obserwuje swoje obiekty-dzieci wydaje mi sie
> > dziwne.
>
> Dlaczego ?.

Uwazam ze nazywanie tego prostego mechanizmu Observerem jest troche
mylace.
Gdyby Przemek napisal ze Manager przekazuje swoim obiektom interfejs do
notyfikacji wszystko byloby jasne i nie trzeba byloby niczego
odszyfrowywac.

> Przeciez to jest jak najbardziej naturalne i rzeczywiste.
> Pracodawca (manager) obserwuje swoich p[racownikow mimo ze oni
> o tym nei musza (a nawet nei powinni) wiedziec.
> Pracownik ma jedynei obowiazek "notyfikowac" o tym co robi
> (odbic karte, wypelnic wnuiossek urlopowy itp).
>
> Manager to ktois kto chce meic informacje o tym czyms zarzadza
> czylki to wlasnei on obserwuje zmainy obiektow obserwowanych.
> Obiekty obserwowane nie powinny miec _zadnej_ informacji o tym
> czy ktos je  obserwuje czy nie i kto to jest itp.
> One jedynie powinny informowac (notyfikacje) o swoich zmianach.
> Informowac w ogole. Nie kogos konkretnego.

Zgadzam sie.
I takie bylo pierwsze podejscie we wspomnianym projekcie.
Niestety komputery maja ograniczone zasoby. Pamiec w szczegolnosci.
Przetwarzalismy duza liczbe stosunkowo malych obiektow.
Koszt 'referencji do managera' (a zwykle do managerow) byl dla nas
znaczacy.

D.

ps: Ja tez nie jestem zawodowym projektantem.

"Darek Kubiczek" <darek_kubiczek@wp.pl> wrote:

>>Adam Karpierz napisał(a):
>> "Darek Kubiczek" <darek_kubiczek@wp.pl> wrote in message
>>
>> > Hmm, wyglada na to ze chyba nie zrozumialem Przemka.
>> > Mi chodzilo o wykorzystanie wzorca Observer nastepujaco: Manager
>> > (obserwowany) i klienci Managera (obserwatorzy).
>> > Podejscie w ktorym Manager obserwuje swoje obiekty-dzieci wydaje mi sie
>> > dziwne.
>>
>> Dlaczego ?.

> Uwazam ze nazywanie tego prostego mechanizmu
> Observerem jest troche mylace.

Po pierwsze, nei nazwalem tego mechanizmu observerem.
Uzywalem normalnych slow: manager/obiekty

> Gdyby Przemek napisal ze Manager przekazuje swoim obiektom
> interfejs do notyfikacji wszystko byloby jasne i nie trzeba byloby niczego
> odszyfrowywac.

A po co manager ma przekazywac jakis interface ?
Jednak masz zakorzenione spojrzenie na problem ze swiata
"patternomanii" gdzie zwykle  w opisywanych realizacjach Observera
obiekty wywoluja cos na managerze (rejestruja sie w nim itp).
Rezczywistosc jest i inna i prostrza.
"Classic" Observer to nie zaden dogmat ! ;)

Classic specjalnie w ciapkach bo co to mi za classic
w ktorym wiecej technikaliow niz odzwierciedlenia
"swiata rzeczywistego".

> Manager to ktois kto chce meic informacje o tym czyms zarzadza
> czylki to wlasnei on obserwuje zmainy obiektow obserwowanych.
> Obiekty obserwowane nie powinny miec _zadnej_ informacji o tym
> czy ktos je  obserwuje czy nie i kto to jest itp.
> One jedynie powinny informowac (notyfikacje) o swoich zmianach.
> Informowac w ogole. Nie kogos konkretnego.

> Zgadzam sie.
> I takie bylo pierwsze podejscie we wspomnianym projekcie.
> Niestety komputery maja ograniczone zasoby. Pamiec w szczegolnosci.

Dales koronny dowod tezy ktora podalem juz na poczatku.
Zwyciestwo "technikaliow" nad rzeczywistoscia.

> Przetwarzalismy duza liczbe stosunkowo malych obiektow.
> Koszt 'referencji do managera' (a zwykle do managerow)
> byl dla nas znaczacy.

Ale..
A po co obiekty maja miec referencje do managera ?
Nie mowie ze nie moga ale czy musza ?
Nie mozna tego zrealizowac inaczej czyli tak jak w zyciu ?
Przeciez gdy "odbijasz karte" po przyjsciu do pracy to wcale
nie musisz informowac o tym natychmiast managera.
Po prostu _zdarzylo sie_ ze odbiles.
Wszystko.

AK

Adam Karpierz wrote:

<ciah>

> Ale..
> A po co obiekty maja miec referencje do managera ?
> Nie mowie ze nie moga ale czy musza ?
O ile manager nie jest singletonem to musza bo...

> Nie mozna tego zrealizowac inaczej czyli tak jak w zyciu ?
> Przeciez gdy "odbijasz karte" po przyjsciu do pracy to wcale
> nie musisz informowac o tym natychmiast managera.
> Po prostu _zdarzylo sie_ ze odbiles.
Ale odbija sie na czyms, czyli na zegarze, jezeli jest jeden zegar w 
fabryce (manager jest singletonem) wiadomo gdzie isc zeby odbic, jezeli 
jest ich wiele i kazdy pracownik ma przypisany swoj zegar to pracownik 
musi pamietac do ktorego zegara ma isc (czyli obiekt musi trzymac 
referencje na managera)
> Wszystko.
Ano wszystko.

-- 
a1 (Bartek Janusz) arcone1 gmail com

"a1" <a1@no.spam> wrote:

>> Ale..
>> A po co obiekty maja miec referencje do managera ?
>> Nie mowie ze nie moga ale czy musza ?
> O ile manager nie jest singletonem to musza bo...

Nie musza.

>> Nie mozna tego zrealizowac inaczej czyli tak jak w zyciu ?
>> Przeciez gdy "odbijasz karte" po przyjsciu do pracy to wcale
>> nie musisz informowac o tym natychmiast managera.
>> Po prostu _zdarzylo sie_ ze odbiles.
> Ale odbija sie na czyms, czyli na zegarze, jezeli jest jeden zegar w 
> fabryce (manager jest singletonem) wiadomo gdzie isc zeby odbic, jezeli 
> jest ich wiele i kazdy pracownik ma przypisany swoj zegar to pracownik 
> musi pamietac do ktorego zegara ma isc (czyli obiekt musi trzymac 
> referencje na managera)

Zegar wcale nie musi miec cos wspolnego z managerem
(a juz tym bardziej zeby nim bez posrednio byl).
Zegar jest zaledwie jednym ze "zbieraczy zdarzen".

Slowem (bo juz mi sie nie chce ciagnac tego watku) do opisanej
przez Przemka sytuacji osobiscie najbardziej "pasuje" mi
"wzorzec rzeczywisty" czyli.

1. Sa sobie obiekty ktore generuja zdarzenia
2. Sa sobie "zbieracze zdarzen" jak wspomniany zegar
    panie w kadrach, itp. Mozna takiego zbieracza nazwac
   brzydko zarzadca zdarzen.
3. Sa sobie managerowie ktorzy sa zainteresowani
     informacjami o zdarzeniach generowanych przez obiekty.
     W tym celu rejestruja sie w "zbieraczach" na odpowiednia usluge
      (np daj dzienny raport przyjsc do pracy) o odpowiednich kryteriach
     (tu wchodzi cala sprawa uprawnien, autoryzacji itp pobocznych rzeczy).
     Jednym z kryteriow moze byc np to ze obiekt generujacy zdarzenie
      ma byc okreslonego typu i np przynalezec do grupu "Moj' :).

"Klasyczny" wzorzec Obeserver jest tylko obcieta wersja tego prostego
jak drut modelu zdarzeniowego. Wersja w ktorej "zbieracz zdarzen"
jest jednoczesnie managerem.
Tyle tylko czy w rzeczywistosci.. gdy przychodzisz do pracy
to odbijasz karte bezposrednio w paszczece kierownika ?

Ten ogolniejszy model oparty na "programowaniu zdarzeniowym"
ma  na pewno jedna niezaprzeczalna zalete.
Zupelnie oddziela swiaty (interfaces) obiektow od interface
managera/row.
Dziejej sie asynchronicznie.
W dodatku jest najblizszy rzeczywistosci "realnej" a nie
"IT technikalnej".

Wiem wiem.. jest problem muchy i armaty..
Na to jednak nie ma recepty poza dokladnym
rozpatrzeniem _konkretnego_ przypadku.
Tu nie wystarczy informacja "jest sobie manager i obiekty"
Tu trzeba wiedziec wiecej o tym co ta para realnie modeluje.

PS: tak tak... jestem zwolennikiem OO i "programowania zdarzeniowego".
        Sa chyba najblizej rzeczywistosci ze znanych mi "paradygmatow".
        Slowem (mowiac nowomowa IT): niech zyja kolejki zdarzen :)

PS1: Tak z ciekawosci: Jaki wzorzec/wzorce mozna przypasowac do w/w ?

EOT

AK

Dnia Wed, 12 Jul 2006 17:03:13 +0200, Adam Karpierz skrobie:
> > Gdyby Przemek napisal ze Manager przekazuje swoim obiektom
> > interfejs do notyfikacji wszystko byloby jasne i nie trzeba byloby niczego
> > odszyfrowywac.

> A po co manager ma przekazywac jakis interface ?

No, powiedzmy że manager musi być w jakiś sposób dostępny dla obiektów,
którymi zarządza.

> Jednak masz zakorzenione spojrzenie na problem ze swiata
> "patternomanii" gdzie zwykle  w opisywanych realizacjach Observera
> obiekty wywoluja cos na managerze (rejestruja sie w nim itp).

Jakim managerze??? We wzorcu Observera nie ma słowa o żadnym managerze. Jest
obiekt obserwowany i obiekty obserwujące.

> Rezczywistosc jest i inna i prostrza.
> "Classic" Observer to nie zaden dogmat ! ;)

Proponowałbym ci najpierw zapoznać się z wzorcem Observera. Linka podałem.

> Classic specjalnie w ciapkach bo co to mi za classic
> w ktorym wiecej technikaliow niz odzwierciedlenia
> "swiata rzeczywistego".

Nie ma żadnych technikaliów we wzorcu Observera. Kwestia istnienia stanów,
zachodzenia zdarzeń i obserwowania ich nie ma nic wspólnego z technikaliami. A
o niczym więcej wzorzec Observer nie mówi.

> > Manager to ktois kto chce meic informacje o tym czyms zarzadza
> > czylki to wlasnei on obserwuje zmainy obiektow obserwowanych.
> > Obiekty obserwowane nie powinny miec _zadnej_ informacji o tym
> > czy ktos je  obserwuje czy nie i kto to jest itp.
> > One jedynie powinny informowac (notyfikacje) o swoich zmianach.
> > Informowac w ogole. Nie kogos konkretnego.

> > Zgadzam sie.
> > I takie bylo pierwsze podejscie we wspomnianym projekcie.
> > Niestety komputery maja ograniczone zasoby. Pamiec w szczegolnosci.

> Dales koronny dowod tezy ktora podalem juz na poczatku.
> Zwyciestwo "technikaliow" nad rzeczywistoscia.

W tym sensie, to zwycięstwo technikaliów nad rzeczywistością będzie miało
miejsce bardzo często :)

> > Przetwarzalismy duza liczbe stosunkowo malych obiektow.
> > Koszt 'referencji do managera' (a zwykle do managerow)
> > byl dla nas znaczacy.

> Ale..
> A po co obiekty maja miec referencje do managera ?
> Nie mowie ze nie moga ale czy musza ?

To wszystko zależy, właśnie od modelu hierarchii. W szczególności o przepływie
informacji. Jeśli interesuje nas przepływ informacji tylko w jedną stronę,
czyli taki model "despotyczny" ("Góra mówi, dół słucha" - skąd to znamy?:), to
wtedy obiekty nie muszą mieć referencji do managera. Jeśli jednak istnieje
jakikolwiek przepływ informacji również w drugą stronę (a często istnieje), to
bez referencji do managera się nie obejdzie.

> Nie mozna tego zrealizowac inaczej czyli tak jak w zyciu ?

Masz może na myśli wspomniany cytat? Już to "w życiu" przerabialiśmy.

> Przeciez gdy "odbijasz karte" po przyjsciu do pracy to wcale
> nie musisz informowac o tym natychmiast managera.

Oczywiście, ale ty mówisz o sytuacji, gdy pracownik nawet w ogóle nie odbija
karty.

> Po prostu _zdarzylo sie_ ze odbiles.

Czekaj, czekaj.

Mówisz teraz o idei, czy o technikaliach?

Jedną z form realizacji Observera jest mechanizm sygnałów i slotów, w
szczególności odbiornik jest obiektem obserwującym, a nadajnik obiektem
obserwowanym. Realizacja (uwaga! mówię o technikaliach) tego polega na tym, że
obiekt sygnału (który jest posiadany przez nadajnik) zawiera w sobie zbiornik
z referencjami do slotów, posiadanych przez odbiorniki.

Jeśli przystawimy to teraz to teorii, że manager słucha pracowników, to w
takim razie pracownik jest nadajnikiem, a manager odbiornikiem. Kto z nich
posiada jakie referencje, i do czego, a kto z nich nie posiada? Odpowiedz
sobie sam.

Natomiast ideologicznie, oczywiście, żaden obiekt nic nie wie o drugim.
Rzeczywiście, obiekt nadajnika i odbiornika posiadają odpowiednio sygnał i
slot, ale jawnie żadnych referencji do obiektów nie posiadają. Tylko co to ma
do rzeczy? Fizycznie te referencje istnieją, tyle że są ukryte w obiekcie
sygnału.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ 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" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
wrote:

>> A po co manager ma przekazywac jakis interface ?
>
> No, powiedzmy że manager musi być w jakiś sposób dostępny dla obiektów,
> którymi zarządza.

Nie powiedzmy.
_Kompletnie nie musi_.
Wlasciwie nie powinien.

>> Jednak masz zakorzenione spojrzenie na problem ze swiata
>> "patternomanii" gdzie zwykle  w opisywanych realizacjach Observera
>> obiekty wywoluja cos na managerze (rejestruja sie w nim itp).
>
> Jakim managerze??? We wzorcu Observera nie ma słowa o żadnym managerze.
> Jest obiekt obserwowany i obiekty obserwujące.

No tak.. Tutaj mamy kliniczny przyklad tego co napisal A.L.
<cytat>
W dyskusjach "patternowych" srodki
pzreslaniaja cel. Na ogol zapomina sie "po co i dlaczego" a patrzy
sie czy projekt ejst zgodny z podrecznikiem.
</cytat>

Wiesz jeszcze czego w ogole dotyczyli meritum czy juz masz w glowie
_tylko_ Observer.. Observer..

>> Rezczywistosc jest i inna i prostrza.
>> "Classic" Observer to nie zaden dogmat ! ;)
>
> Proponowałbym ci najpierw zapoznać się z wzorcem Observera.
> Linka podałem.

Po jaka cholere ?
Mam swoj "pattern" bardzo dobrze oddajacy rzeczywisctosc.
Po co mi cos jeszcze ?

>> Classic specjalnie w ciapkach bo co to mi za classic
>> w ktorym wiecej technikaliow niz odzwierciedlenia
>> "swiata rzeczywistego".
>
> Nie ma żadnych technikaliów we wzorcu Observera. Kwestia istnienia stanów,
> zachodzenia zdarzeń i obserwowania ich nie ma nic wspólnego z 
> technikaliami. A
> o niczym więcej wzorzec Observer nie mówi.

Mowi o rejestracji przez obiekty obserwatorow czy nie mowi ?

>> Dales koronny dowod tezy ktora podalem juz na poczatku.
>> Zwyciestwo "technikaliow" nad rzeczywistoscia.
>
> W tym sensie, to zwycięstwo technikaliów nad rzeczywistością
> będzie miało miejsce bardzo często :)

Kompletna bzdura.
Zmiana modelu tylko po to aby uzyskac "wydajnosc"
zamiast uzyskania "wydajnosci" droga optymalizacji i szukania
bottle neck-ow istneijacego _prawidlowego_ modelu jest typowym
przykladem zlego podejscia do projektowania/programowania
_w ogole_.

>
>> > Przetwarzalismy duza liczbe stosunkowo malych obiektow.
>> > Koszt 'referencji do managera' (a zwykle do managerow)
>> > byl dla nas znaczacy.
>
>> Ale..
>> A po co obiekty maja miec referencje do managera ?
>> Nie mowie ze nie moga ale czy musza ?
>
> To wszystko zależy, właśnie od modelu hierarchii.
> W szczególności o przepływie
> informacji. Jeśli interesuje nas przepływ informacji tylko w jedną stronę,
> czyli taki model "despotyczny" ("Góra mówi, dół słucha" - skąd to 
> znamy?:), to
> wtedy obiekty nie muszą mieć referencji do managera. Jeśli jednak istnieje
> jakikolwiek przepływ informacji również w drugą stronę (a często 
> istnieje), to
> bez referencji do managera się nie obejdzie.

Nie rozsmieszaj mnie.
Obejdzie sie i to w sposob lepszy.

>> Przeciez gdy "odbijasz karte" po przyjsciu do pracy to wcale
>> nie musisz informowac o tym natychmiast managera.
>
> Oczywiście, ale ty mówisz o sytuacji, gdy pracownik nawet w ogóle nie 
> odbija
> karty.

A skad ci cus takeigo przyszlo do glowy ?

>> Po prostu _zdarzylo sie_ ze odbiles.
>
> Czekaj, czekaj.
>
> Mówisz teraz o idei, czy o technikaliach?

Mowie o zyciu.
Nie zauwazyles ze w zyciu wystepuja najnormalniejsze wv swiecie
zdarzenia ?

> Jedną z form realizacji Observera

No i ten dalej swoje. .. Observer i Observer :)

> Natomiast ideologicznie, oczywiście, żaden obiekt nic nie wie o drugim.
> Rzeczywiście, obiekt nadajnika i odbiornika posiadają odpowiednio sygnał i
> slot, ale jawnie żadnych referencji do obiektów nie posiadają.
> Tylko co to ma do rzeczy?
> Fizycznie te referencje istnieją, tyle że są ukryte w obiekcie sygnału.

I co ? I Ty nie widzisz roznicy ?
Roznica jest _zasadnicza_.

AK

Dnia Wed, 12 Jul 2006 18:59:46 +0200, Adam Karpierz skrobie:
> Zegar wcale nie musi miec cos wspolnego z managerem
> (a juz tym bardziej zeby nim bez posrednio byl).
> Zegar jest zaledwie jednym ze "zbieraczy zdarzen".

> Slowem (bo juz mi sie nie chce ciagnac tego watku) do opisanej
> przez Przemka sytuacji osobiscie najbardziej "pasuje" mi
> "wzorzec rzeczywisty" czyli.

Adamie, im bardziej przystawiasz to do "rzeczywistego życia", tym bardziej
oddalasz się od "rzeczywistości oprogramowania".

Nie dlatego, żeby były między nimi aż takie różnice. To dlatego, że w jednym i
w drugim jest bardzo wiele szczegółów, którytch ty nie dostrzegasz. Twoja
wizja "rzeczywistości" jest mocno uproszczona, a niestosowalność danego
rozwiązania, które funkcjonuje w "rzeczywistości" w oprogramowaniu wynika z
jeszcze innej, prozaicznej przyczyny: czy próbowałeś sobie kiedyś wyobrazić,
jak wyglądałoby oprogramowanie, gdyby było pisane przez prawników?

> 1. Sa sobie obiekty ktore generuja zdarzenia
> 2. Sa sobie "zbieracze zdarzen" jak wspomniany zegar
>     panie w kadrach, itp. Mozna takiego zbieracza nazwac
>    brzydko zarzadca zdarzen.
> 3. Sa sobie managerowie ktorzy sa zainteresowani
>      informacjami o zdarzeniach generowanych przez obiekty.
>      W tym celu rejestruja sie w "zbieraczach" na odpowiednia usluge
>       (np daj dzienny raport przyjsc do pracy) o odpowiednich kryteriach
>      (tu wchodzi cala sprawa uprawnien, autoryzacji itp pobocznych rzeczy).
>      Jednym z kryteriow moze byc np to ze obiekt generujacy zdarzenie
>       ma byc okreslonego typu i np przynalezec do grupu "Moj' :).

Super, pomysł jest dobry, co więcej, nawet stosowany, tyle że nie zawsze i
rzadko kiedy w funkcjonujących systemach. Wyobraź sobie np. gdybyś to
zastosował w systemie operacyjnym "dzienne raporty z usunięć plików". Ciekawe,
kiedy by ci nagle zaczęło na moment dziwnie brakować miejsca na dysku.
Zresztą, zróbmy to też tak, jak ty: wyobraź sobie, że straż pożarna ma usługę
"dzienny raport zgłoszeń pożarów". Albo pogotowie ratunkowe "dzienny raport
zgłoszeń zawału serca".

Oczywiście, że może istnieć jakiś "kontroler zdarzeń", tyle że to właśnie ten
kontroler zdarzeń staje się po części w pewnym sensie managerem: zbiera
zgłoszenia i zapamiętuje. Oczywiście, że może istnieć taki obiekt, a obiekt
faktycznego managera jest obiektem zupełnie oddzielnym i korzysta z
pośrednictwa kontrolera zdarzeń w pewnych sprawach - ale realizacja takiego
przedsięwzięcia musi być najpierw przeanalizowana pod kątem tego, czy to
rzeczywiście spełnia nasze wymagania odnośnie czasu dostarczenia raportu i czy
zdarzenie ma obsługę synchroniczną, oraz czy istnieje rzeczywiście taka
potrzeba, żeby istniał taki dodatkowy obiekt.

To co piszesz, nie jest całkiem bez sensu, jednak bezsensowna jest twoja
krytyka - to, co proponujesz podlega pod zupełnie inne wymagania systemowe i
jest takim "również dobrym rozwiązaniem", tyle że nie dla każdego przypadku.

> "Klasyczny" wzorzec Obeserver jest tylko obcieta wersja tego prostego
> jak drut modelu zdarzeniowego. Wersja w ktorej "zbieracz zdarzen"
> jest jednoczesnie managerem.

Totalna bzdura. Adamie, doczytaj może najpierw dokładniej, o co chodzi we
wzorcu Observer. Zauważ też, że Observer jest wąską specjalizacją
jednostronnej komunikacji, natomiast w żadnym wypadku nie jest modelem
współdziałania managera i pracowników. Nie ma to wręcz z tym nic wspólnego.

> Tyle tylko czy w rzeczywistosci.. gdy przychodzisz do pracy
> to odbijasz karte bezposrednio w paszczece kierownika ?

> Ten ogolniejszy model oparty na "programowaniu zdarzeniowym"
> ma  na pewno jedna niezaprzeczalna zalete.

Oraz jedną niezaprzeczalną wadę.

> Zupelnie oddziela swiaty (interfaces) obiektow od interface
> managera/row.

I co z tego? Ale łączy w sobie interfejs obustronny kontrolera zdarzeń oraz
interfejsy pracowników i managera. Też mi zaleta.

> Dziejej sie asynchronicznie.

Tak, szczególnie te "dzienne raporty" są synchroniczne.

> W dodatku jest najblizszy rzeczywistosci "realnej" a nie
> "IT technikalnej".

W uproszczeniu tak.

> Wiem wiem.. jest problem muchy i armaty..
> Na to jednak nie ma recepty poza dokladnym
> rozpatrzeniem _konkretnego_ przypadku.

Fajnie, gdybyś przed dyskutowaniem tego przykładu sam sobie to wziął do serca.

> Tu nie wystarczy informacja "jest sobie manager i obiekty"
> Tu trzeba wiedziec wiecej o tym co ta para realnie modeluje.

> PS: tak tak... jestem zwolennikiem OO i "programowania zdarzeniowego".

A ja jestem zwolennikiem teorii stanów cząstkowych i technologii sygnałów i
slotów :).

>         Sa chyba najblizej rzeczywistosci ze znanych mi "paradygmatow".
>         Slowem (mowiac nowomowa IT): niech zyja kolejki zdarzen :)

Tak, szczególnie w obsługiwaniu zdarzeń synchronicznych.

> PS1: Tak z ciekawosci: Jaki wzorzec/wzorce mozna przypasowac do w/w ?

Model-View Controller.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ 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" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
wrote:

> Super, pomysł jest dobry, co więcej, nawet stosowany, tyle że nie zawsze i
> rzadko kiedy w funkcjonujących systemach.

Jezuuuu Sekator nie zalamuj mnie !
Jaki polysl ?
Nie napisalem _ani jednego odkrywczego slowa_.
To byl wlasciwie opis czegos co spotyka sie w programowaniu dzisiaj
_wszedzie_.
Przeciez programowanie zdarzeniowe spotyka sie _wszedzie_ od lat.
Ze co ? Ze w OS-ach tego nie ma !!!!?
(ze o oprogramowaniu aplikacyjnym, nie wspomne...).

Poddaje sie .. szkoda mi zdrowia...

>> PS1: Tak z ciekawosci: Jaki wzorzec/wzorce mozna przypasowac do w/w ?
>
> Model-View Controller.

Slabne...

EOT

AK 

Dnia Wed, 12 Jul 2006 22:11:21 +0200, Adam Karpierz skrobie:
> >> Jednak masz zakorzenione spojrzenie na problem ze swiata
> >> "patternomanii" gdzie zwykle  w opisywanych realizacjach Observera
> >> obiekty wywoluja cos na managerze (rejestruja sie w nim itp).
> >
> > Jakim managerze??? We wzorcu Observera nie ma słowa o żadnym managerze.
> > Jest obiekt obserwowany i obiekty obserwuj?ce.

> No tak.. Tutaj mamy kliniczny przyklad tego co napisal A.L.

Tutaj mamy kliniczny przykład "kompleksu Tomasza Nałęcza". Wynajdywanie cytatu
mającego się na bakier z tematem rozmowy, ale bardzo dobrze pozorującego.

IOW: nie wycieraj sobie gęby panem A.L., bo na razie to sam najwyraźniej już
się pogubiłeś w dyskusji.

> Wiesz jeszcze czego w ogole dotyczyli meritum czy juz masz w glowie
> _tylko_ Observer.. Observer..

No cóż, meritum dotyczyło tego, czy w podanym opisie można zastosować wzorzec
Observer. Cała dyskusja jest właśnie o tym.

Możemy dyskutować o tym, jakie najlepsze rozwiązanie można wybrać dla
realizacji managera i obiektów podległych, albo o tym, czy tu jakoś da się
zastosować wzorzec Observer. Ale jeśli mówimy o pierwszym, to zapomnij o
wzorcu Observer (spójrz na swoje wypowiedzi i zobacz, kto o nim tutaj ciągle
trajkocze), a jeśli o drugim, to skupmy się właśnie na wzorcu Observer.

Bo jak na razie to twoja dyskusja polega na tym: jak zrobić, żeby użyć wzorca
Observer, ale tak zupełnie inaczej, a właściwie zrobić własny wzorzec
Observer, chociaż może coś trochę innego, bo ten Observer się do niczego nie
nadaje, w szczególności zupełnie inaczej powinna wyglądać realizacja modelu
zarządzania z udziałem managera i pracowników.

O tym, że wzorzec Observer nie nadaje się do modelu zarządzania z udziałem
managera i pracowników mówiłem na samym początku, jeśli nie zauważyłeś. Jeśli
chcesz żebym nie dyskutował już o wzorcu Observer, to wystarczy jedna prosta
rzecz: sam przestań o nim trajkotać.

> >> Rezczywistosc jest i inna i prostrza.
> >> "Classic" Observer to nie zaden dogmat ! ;)
> >
> > Proponowałbym ci najpierw zapoznać się z wzorcem Observera.
> > Linka podałem.

> Po jaka cholere ?

No, na przykład po to, że jeśli się już coś krytykuje, to wypadałoby nie robić
z siebie idioty i wiedzieć, o czym się mówi.

> Mam swoj "pattern" bardzo dobrze oddajacy rzeczywisctosc.

Ścisłą specjalizację drobnego fragmentu rzeczywistości.

> Po co mi cos jeszcze ?

No, bardzo ci się przyda jeszcze wiaderko wzorców do innych specjalizacji
rzeczywistości. I łyżka zdrowego rozsądku. Taka od koparki.

> >> Classic specjalnie w ciapkach bo co to mi za classic
> >> w ktorym wiecej technikaliow niz odzwierciedlenia
> >> "swiata rzeczywistego".
> >
> > Nie ma żadnych technikaliów we wzorcu Observera. Kwestia istnienia stanów,
> > zachodzenia zdarzeń i obserwowania ich nie ma nic wspólnego z 
> > technikaliami. A
> > o niczym więcej wzorzec Observer nie mówi.

> Mowi o rejestracji przez obiekty obserwatorow czy nie mowi ?

Aha, więc "rejestracja" to są dla ciebie już technikalia? Czy też zadałeś to
pytanie dla formalności?

Jeśli to przystawić do tej twojej "rzeczywistości", to rejestracja w tym
wypadku polega na otrzymaniu karty. I co, technikalia?

> >> Dales koronny dowod tezy ktora podalem juz na poczatku.
> >> Zwyciestwo "technikaliow" nad rzeczywistoscia.
> >
> > W tym sensie, to zwycięstwo technikaliów nad rzeczywisto?ci?
> > będzie miało miejsce bardzo często :)

> Kompletna bzdura.
> Zmiana modelu tylko po to aby uzyskac "wydajnosc"
> zamiast uzyskania "wydajnosci" droga optymalizacji i szukania
> bottle neck-ow istneijacego _prawidlowego_ modelu jest typowym
> przykladem zlego podejscia do projektowania/programowania
> _w ogole_.

Kompletna bzdura.
W rzeczywistym oprogramowaniu model dobiera się adekwatnie do tego, co chcemy
osiągnąć i adekwatnie do wymagań wydajnościowych i zużycia zasobów. Ale nie
przez zmianę modelu; z czymś takim jeszcze się nie spotkałem. A optymalizacje
implementacyjne, na dalszym planie oczywiście, wykonuje się również.

> >> > Przetwarzalismy duza liczbe stosunkowo malych obiektow.
> >> > Koszt 'referencji do managera' (a zwykle do managerow)
> >> > byl dla nas znaczacy.
> >
> >> Ale..
> >> A po co obiekty maja miec referencje do managera ?
> >> Nie mowie ze nie moga ale czy musza ?
> >
> > To wszystko zależy, wła?nie od modelu hierarchii.
> > W szczególno?ci o przepływie
> > informacji. Je?li interesuje nas przepływ informacji tylko w jedn? stronę,
> > czyli taki model "despotyczny" ("Góra mówi, dół słucha" - sk?d to 
> > znamy?:), to
> > wtedy obiekty nie musz? mieć referencji do managera. Je?li jednak istnieje
> > jakikolwiek przepływ informacji również w drug? stronę (a często 
> > istnieje), to
> > bez referencji do managera się nie obejdzie.

> Nie rozsmieszaj mnie.
> Obejdzie sie i to w sposob lepszy.

Ze sposobu, w jaki to opisałeś, wynika głównie to, że absolutnie się nie
obejdzie. Nieważne, czy referencja jest do managera, czy do kontrolera
zdarzeń. Do czegoś musi być. Bez niej nie ma mowy o jakimkolwiek przepływie
informacji w określonym kierunku.

> >> Przeciez gdy "odbijasz karte" po przyjsciu do pracy to wcale
> >> nie musisz informowac o tym natychmiast managera.
> >
> > Oczywi?cie, ale ty mówisz o sytuacji, gdy pracownik nawet w ogóle nie 
> > odbija
> > karty.

> A skad ci cus takeigo przyszlo do glowy ?

Bo tak właśnie napisałeś. Pracownik nie ma referncji do managera i tylko
słucha. Tak to od samego początku opisywałeś.

> >> Po prostu _zdarzylo sie_ ze odbiles.
> >
> > Czekaj, czekaj.
> >
> > Mówisz teraz o idei, czy o technikaliach?

> Mowie o zyciu.
> Nie zauwazyles ze w zyciu wystepuja najnormalniejsze wv swiecie
> zdarzenia ?

Zależy, co dla ciebie znaczy "najnormalniejsze w świecie". Zdarzenia
kolejkowane na przykład nie występują.

> > Jedn? z form realizacji Observera

> No i ten dalej swoje. .. Observer i Observer :)

Sam zacząłeś. Jak przestaniesz sam kłapać o Observerze, to możemy pogadać o
twojej koncepcji.

> > Natomiast ideologicznie, oczywi?cie, żaden obiekt nic nie wie o drugim.
> > Rzeczywi?cie, obiekt nadajnika i odbiornika posiadaj? odpowiednio sygnał i
> > slot, ale jawnie żadnych referencji do obiektów nie posiadaj?.
> > Tylko co to ma do rzeczy?
> > Fizycznie te referencje istniej?, tyle że s? ukryte w obiekcie sygnału.

> I co ? I Ty nie widzisz roznicy ?
> Roznica jest _zasadnicza_.

Ideologicznie tak. Technicznie nie. I chyba o to chodzi. Jeśli nie zauważyłeś,
jestem zwolennikiem takiego podejścia. Ale znam jego praktyczne konsekwencje.


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

Dnia Wed, 12 Jul 2006 22:21:17 +0200, Adam Karpierz skrobie:
> "Sektor van Skijlen" <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
> wrote:

> > Super, pomysł jest dobry, co więcej, nawet stosowany, tyle że nie zawsze i
> > rzadko kiedy w funkcjonuj?cych systemach.

> Jezuuuu Sekator nie zalamuj mnie !
> Jaki polysl ?

No dobrze, koncepcja.

> Nie napisalem _ani jednego odkrywczego slowa_.

No, owszem.

> To byl wlasciwie opis czegos co spotyka sie w programowaniu dzisiaj
> _wszedzie_.

No, z tym wszędzie to byłbym na twoim miejscu bardzo ostrożny. Ale fakt, jest
to powszechnie stosowane (te różne brokery, agenty itp.).

> Przeciez programowanie zdarzeniowe spotyka sie _wszedzie_ od lat.

No, trochę przesadzasz, bo to, co przedstawiłeś stanowi dość wąską
specjalizację programowania zdarzeniowego.

> Ze co ? Ze w OS-ach tego nie ma !!!!?

Oczywiście, że jest. Tak działał system z jądrem Mach, tak działają też
aplikacje pod VxWorksem. No, o Windowsie nie będę wspominał, bo wstyd ;)

> (ze o oprogramowaniu aplikacyjnym, nie wspomne...).

To też zależy. To jest zwykle część interfejsu użytkownika, a nie wewnętrznej
funkcjonalności.

> Poddaje sie .. szkoda mi zdrowia...

Starzejesz się ;)

> >> PS1: Tak z ciekawosci: Jaki wzorzec/wzorce mozna przypasowac do w/w ?
> >
> > Model-View Controller.

> Slabne...

Nie powiem, żebym nie był usatysfakcjonowany. :)


PS. Tak na marginesie, to ja jestem straszny lamer. Studiowałem
elektrotechnikę, programowania nauczyłem się wyłącznie sam. Nigdy nie byłem na
żadnych studiach informatycznych, nigdy nie zakuwałem żadnych teorii
projektowania z książek, a większość informacji, jakie posiadam, pochodzą z
netu, często kierowane z grup dyskusyjnych. Twierdzenie zatem, że stosuję tu
jakąś książkową wiedzę przyprawiają mnie o skrajne LOL-e.


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

Adam Karpierz wrote:

> Slowem (bo juz mi sie nie chce ciagnac tego watku) do opisanej
> przez Przemka sytuacji osobiscie najbardziej "pasuje" mi
> "wzorzec rzeczywisty" czyli.
> 
> 1. Sa sobie obiekty ktore generuja zdarzenia
> 2. Sa sobie "zbieracze zdarzen" jak wspomniany zegar
>     panie w kadrach, itp. Mozna takiego zbieracza nazwac
>    brzydko zarzadca zdarzen.
Nadal pozostaje problem przypisania pracownik - zegar, jezeli kazdy z 
pracownikow ma przypisany konkretny zegar musi o tym pamietac a wiec 
musi miec referencje na obiekt "zbieracza zdarzen".

> Ten ogolniejszy model oparty na "programowaniu zdarzeniowym"
> ma  na pewno jedna niezaprzeczalna zalete.
To jest oczywiste, jednak zdarzenia nie sa wysylane w blizej 
nieokreslona przestrzen, nastepuje zestawienie konkretnego nadawcy z 
odbiorca (odbiorcami), stad koniecznosc pamietania referencji do 
managera (jawnie lub nie, ale w wypadku opisanym w pierwszym poscie 
konieczne byloby jawne polaczenie, lub ewentualnie, gdyby implementowac 
to w javie prawie jawne - inner class).

-- 
a1 (Bartek Janusz) arcone1 gmail com

"a1" <a1@no.spam> wrote:

>> 1. Sa sobie obiekty ktore generuja zdarzenia
>> 2. Sa sobie "zbieracze zdarzen" jak wspomniany zegar
>>     panie w kadrach, itp. Mozna takiego zbieracza nazwac
>>    brzydko zarzadca zdarzen.
> Nadal pozostaje problem przypisania pracownik - zegar, jezeli kazdy z 
> pracownikow ma przypisany konkretny zegar musi o tym pamietac a wiec musi 
> miec referencje na obiekt "zbieracza zdarzen".

pracownik.OdbijKarte(zegar);

pracownik.OddajKadrowejKarteUrlopowa(paniKunegunda);

>> Ten ogolniejszy model oparty na "programowaniu zdarzeniowym"
>> ma  na pewno jedna niezaprzeczalna zalete.
> To jest oczywiste, jednak zdarzenia nie sa wysylane w blizej nieokreslona 
> przestrzen, nastepuje zestawienie konkretnego nadawcy z odbiorca 
> (odbiorcami),

Nie.
Zdarzenia trafiaja do kolejki zdarzen
(czy ogolniej do zbieracza/managera zdarzen).
Nadawca nic nie wie o managerze.
Wie tylko chwilowo o kolejce zdarzen jak w/w.

AK

"a1" <a1@no.spam> wrote:

>> 1. Sa sobie obiekty ktore generuja zdarzenia
>> 2. Sa sobie "zbieracze zdarzen" jak wspomniany zegar
>>     panie w kadrach, itp. Mozna takiego zbieracza nazwac
>>    brzydko zarzadca zdarzen.
> Nadal pozostaje problem przypisania pracownik - zegar, jezeli kazdy z 
> pracownikow ma przypisany konkretny zegar musi o tym pamietac a wiec musi 
> miec referencje na obiekt "zbieracza zdarzen".

zegar.OdbicieKarty(pracownik);

paniKunegunda.OddanieKartyUrlopowej(pracownik);

>> Ten ogolniejszy model oparty na "programowaniu zdarzeniowym"
>> ma  na pewno jedna niezaprzeczalna zalete.
> To jest oczywiste, jednak zdarzenia nie sa wysylane w blizej nieokreslona 
> przestrzen, nastepuje zestawienie konkretnego nadawcy z odbiorca 
> (odbiorcami),

Nie.
Zdarzenia trafiaja do kolejki zdarzen
(czy ogolniej do zbieracza/managera zdarzen).
Nadawca nic nie wie o managerze.
Wie tylko chwilowo o kolejce zdarzen jak w/w.

AK

Adam Karpierz wrote:
> "a1" <a1@no.spam> wrote:
> 
> 
>>>1. Sa sobie obiekty ktore generuja zdarzenia
>>>2. Sa sobie "zbieracze zdarzen" jak wspomniany zegar
>>>    panie w kadrach, itp. Mozna takiego zbieracza nazwac
>>>   brzydko zarzadca zdarzen.
>>
>>Nadal pozostaje problem przypisania pracownik - zegar, jezeli kazdy z 
>>pracownikow ma przypisany konkretny zegar musi o tym pamietac a wiec musi 
>>miec referencje na obiekt "zbieracza zdarzen".
> 
> 
> pracownik.OdbijKarte(zegar);
> pracownik.OddajKadrowejKarteUrlopowa(paniKunegunda);
A skad wezmiemy instancje zegar lub instancje paniKunegunda (przy 
zalozeniu ze kazdy pracownik ma swoj jeden konkretny zegar lub jeda 
konkretna pania Kunegunde).

> Nie.
> Zdarzenia trafiaja do kolejki zdarzen
> (czy ogolniej do zbieracza/managera zdarzen).
> Nadawca nic nie wie o managerze.
> Wie tylko chwilowo o kolejce zdarzen jak w/w.
Tak i zostaje w tej kolejce zdarzen, kolejka zdarzen jest obiektem 
pomocniczym i wogole nie powinnien byc ty rozwazany (czyzby zwyciestwo 
technikali?), ostatenie z kolejki zdarzenie musi trafic do okreslonego 
odbiorcy, wiec w zdarzeniu musi byc odpowiednia informacja gdzie ma 
trafic - skad sie bierze ta informacja anao stad ze nadawca wysyla 
zdarzenie do okreslonego odbiorcy (stad tez koniecznosc jawnej lub 
niejawnej referencji do odbiorcy w obiekcie nadawcy).

-- 
a1 (Bartek Janusz) arcone1 gmail com

"a1" <a1@no.spam> wrote:

>> pracownik.OdbijKarte(zegar);
>> pracownik.OddajKadrowejKarteUrlopowa(paniKunegunda);

Pomyslilem sie (stan cancel poprzedniego posta).
Ma byc

zegar.OdbicieKarty(pracownik);
paniKunegunda.OddanieKartyUrlopowej(pracownik);

> A skad wezmiemy instancje zegar lub instancje paniKunegunda (przy 
> zalozeniu ze kazdy pracownik ma swoj jeden konkretny zegar lub jeda 
> konkretna pania Kunegunde).

Zle zalozenie (bo wrzeczywistoci tak nie jest).
Jelsi nawet to lepije zrobic jakis mapping typu:

zegary[pracownik].OdbicieKarty(pracownik);

Niz zmieniac interface pracownika.
Pomysl troche.
Czy zegar do kart czy kadrowa jest immanentna cecha/atrybutem
pracownika ?
Przeciez to byt zewnetrzny.
To ze jest (a raczej moze byc) relacja miedzy nimi to nei znaczy
ze musi byc to atrybut pracownika.
Atrybut to jest to co jest czescia pracownika (reka, glowa)
(zaleznosc zawierania, slowem: 'ma').

(Czysta obiektowka nie zbawi swiata: czasem podejscie mieszane
  obiektowo relacyjne lepiej oddaje rzeczywistosc).

> Tak i zostaje w tej kolejce zdarzen, kolejka zdarzen jest obiektem 
> pomocniczym i wogole nie powinnien byc ty rozwazany (czyzby zwyciestwo 
> technikali?),

Kurde.. to nie zaden obiekt pomocniczy
Przeciez wystepuje w rzeczywiscosci
ja najbardziej.

> ostatenie z kolejki zdarzenie musi trafic do okreslonego odbiorcy,

Nie musi. Moze ale nie musi.

> wiec w zdarzeniu musi byc odpowiednia informacja gdzie ma trafic -

Absolutnei nie.
W zdarzeniu _nie ma_ zadnej informacji kto bedzie jego odbiorca.
W zdarzeniu jest tylkoinformacja 'co sie stalo' oraz 'kto' je spowodowal.
O odbiorcy ani slowa.

> skad sie bierze ta informacja anao stad ze nadawca wysyla zdarzenie do 
> okreslonego odbiorcy

Nieprawda.
Nadawca wysyla zdarzenie "w ciemnosc" (czyli do kolejki zdarzen)
Tyle.

> (stad tez koniecznosc jawnej lub niejawnej referencji do odbiorcy w 
> obiekcie nadawcy).

No i co z tego ?
Czy nie rozrozniasz zewnetrzna referencje (w klasie managera lub obiektu) od
zewnetrznej  referencji 'relacyjnej' ?
Przeciez tu chodzi o to ze zewnetrzna relacja nie wymaga
zmiany interface obiektu.
Nie widzisz zadnej roznicy dalej ?
Dla mnie roznica jest zasadnicza.

AK 

Adam Karpierz wrote:

> Zle zalozenie (bo wrzeczywistoci tak nie jest).
w problemie z orginalnego postu jest, w wiekszosci systemow eventowych tez
> Jelsi nawet to lepije zrobic jakis mapping typu:
> 
> zegary[pracownik].OdbicieKarty(pracownik);
jak wspominaem jawna lub niejawna referencja

<ciah>

> Kurde.. to nie zaden obiekt pomocniczy
> Przeciez wystepuje w rzeczywiscosci
> ja najbardziej.
Lub nie, zalezy od implementacji - czyli nie warte uwagi technikalia.

>>ostatenie z kolejki zdarzenie musi trafic do okreslonego odbiorcy,
> 
> Nie musi. Moze ale nie musi.
Jezeli specyfikacja funkcjonalna wymaga zeby trafil do okreslonego 
odbiorcy to musi (a w 90% przypadkow tak jest).

<ciah>

> No i co z tego ?
> Czy nie rozrozniasz zewnetrzna referencje (w klasie managera lub obiektu) od
> zewnetrznej  referencji 'relacyjnej' ?
> Przeciez tu chodzi o to ze zewnetrzna relacja nie wymaga
> zmiany interface obiektu.
> Nie widzisz zadnej roznicy dalej ?
> Dla mnie roznica jest zasadnicza.
To tylko szczegol implementacyjny, jezeli jest relacja to musi byc 
referencja, w orginalnym problemie relacja istnieje (sesja nalezy do 
okreslonego managera) wiec referencja byc musi (czy to bedzie referencja 
w sensie javowym, czy jakies id, czy mapowanie nadawca/broker czy tez 
nawet filtr na nadawcow w odbiorcy nie ma najmniejszego znaczenia - to 
tylko technikalia).

-- 
a1 (Bartek Janusz) arcone1 gmail com

"a1" <a1@no.spam> wrote in message news:e959lm$haq$1@inews.gazeta.pl...

>> zegary[pracownik].OdbicieKarty(pracownik);
> jak wspominaem jawna lub niejawna referencja

To nie jest referencja.
Relacja nie jest referencja.

>> Kurde.. to nie zaden obiekt pomocniczy
>> Przeciez wystepuje w rzeczywiscosci
>> ja najbardziej.
> Lub nie, zalezy od implementacji - czyli nie warte uwagi technikalia.

To nie zalezy od implementacji
"zbieracz zdarzen" jest czescia _modelu_ a nie jego implementacji
Wiec nie sa to zadne technikalia.
No chyba ze chcesz w implementacji "upraszacc" model
No to gratuluje.

>>>ostatenie z kolejki zdarzenie musi trafic do okreslonego odbiorcy,
>>
>> Nie musi. Moze ale nie musi.
> Jezeli specyfikacja funkcjonalna wymaga zeby trafil do okreslonego 
> odbiorcy to musi (a w 90% przypadkow tak jest).

Wiec owszem. Moze.
To 10%  stanowi o "moze" a nie 'musi'.
Nogdy natomiast nei jest potrzebne bezposrednie
'silne' zwiazanie obiektu z managerem.

>> No i co z tego ?
>> Czy nie rozrozniasz zewnetrzna referencje (w klasie managera lub obiektu) 
>> od
>> zewnetrznej  referencji 'relacyjnej' ?
>> Przeciez tu chodzi o to ze zewnetrzna relacja nie wymaga
>> zmiany interface obiektu.
>> Nie widzisz zadnej roznicy dalej ?
>> Dla mnie roznica jest zasadnicza.
> To tylko szczegol implementacyjny,

Koniecznosc zmiany interface obiektu to szczegol implementacyjny ?
Zastanowiles sie co mowisz ?
Zreszta to odpowiada rzeczywisctosci.
Dodanie atrybutu 'zegar' do interface pracownika
jest smeiszne, bo sugeruje ze pracownik
na czole ma zegar zamiast zmarszczek.

> jezeli jest relacja to musi byc referencja,

Nie.

> w orginalnym problemie relacja istnieje (sesja nalezy do okreslonego 
> managera) wiec referencja byc musi (czy to bedzie referencja w sensie 
> javowym, czy jakies id, czy mapowanie nadawca/broker czy tez nawet filtr 
> na nadawcow w odbiorcy nie ma najmniejszego znaczenia - to tylko 
> technikalia).

Ma zasadnicze znaczenie.
Juz w modelu ma zasadnicze znaczenie.
Model _ma_ obrazowac rzeczywisctosc a nie jakies
abstrakcyjne szmoje boje.

AK

Adam Karpierz napisał(a):
> >> Dlaczego ?.
>
> > Uwazam ze nazywanie tego prostego mechanizmu
> > Observerem jest troche mylace.
>
> Po pierwsze, nei nazwalem tego mechanizmu observerem.
> Uzywalem normalnych slow: manager/obiekty

Adam, gdzie ja napisalem ze to Ty nazwales ten mechanizm Observerem ?

> > Gdyby Przemek napisal ze Manager przekazuje swoim obiektom
> > interfejs do notyfikacji wszystko byloby jasne i nie trzeba byloby niczego
> > odszyfrowywac.
>
> A po co manager ma przekazywac jakis interface ?

Bo tak jest najprosciej ?
Bo nie chcemy/nie mozemy uzyc Singletona ?
Bo Twoje odzwierciedlanie rzeczywistosci w programach bardzo komplikuje
tworzenie tych programow ? A i tak bez technikaliow sie pewnie nie
obedzie.

> Jednak masz zakorzenione spojrzenie na problem ze swiata
> "patternomanii"

:)

> gdzie zwykle  w opisywanych realizacjach Observera
> obiekty wywoluja cos na managerze (rejestruja sie w nim itp).
> Rezczywistosc jest i inna i prostrza.

Tak prosta ze potrzebujemy do jej modelowania komunikacji
asynchronicznej, kolejek, eventow itd. ?

> > Przetwarzalismy duza liczbe stosunkowo malych obiektow.
> > Koszt 'referencji do managera' (a zwykle do managerow)
> > byl dla nas znaczacy.
>
> Ale..
> A po co obiekty maja miec referencje do managera ?
> Nie mowie ze nie moga ale czy musza ?

Nie musza.

> Nie mozna tego zrealizowac inaczej czyli tak jak w zyciu ?

Mozna. Jestem zwolennikiem takiego podejscia.
Ale w praktyce nie zawsze jest to takie proste.

Najprawdopodobniej wprowadzenie do tego projektu o ktorym pisalem
"modelu zdarzeniowego" skonczyloby sie dla mnie poszukiwaniem nowej
pracy.

D.

Adam Karpierz wrote:

<ciah>

> Wiec owszem. Moze.
> To 10%  stanowi o "moze" a nie 'musi'.
> Nogdy natomiast nei jest potrzebne bezposrednie
> 'silne' zwiazanie obiektu z managerem.
W orginalnym problemie _MUSI_, a czy wiazanie jest bezposrednie czy 
posrednie to szczegol implementacyjny.

> Koniecznosc zmiany interface obiektu to szczegol implementacyjny ?
> Zastanowiles sie co mowisz ?
A czy ja gdzies wspominalem o zmianie interfejsu? Atrybut nie koniecznie 
musi byc publiczny.
> Zreszta to odpowiada rzeczywisctosci.
> Dodanie atrybutu 'zegar' do interface pracownika
> jest smeiszne, bo sugeruje ze pracownik
> na czole ma zegar zamiast zmarszczek.
To moze po prostu go lepiej nie dodawac?

> Ma zasadnicze znaczenie.
> Juz w modelu ma zasadnicze znaczenie.
> Model _ma_ obrazowac rzeczywisctosc a nie jakies
> abstrakcyjne szmoje boje.
Model ma przyblizac w jak najprostszy sposob rzeczywistosc tworzenie 
modelu bedacego lustrzanym odbiciem danego problemu nie ma sensu - bo 
zamiast modelowac kopiujemy.

Problem jest prosty mamy nadawce zdarzen i odbiorce zdarzen przy czym 
dany odbiorca odbiera zdarzenia tylko od okreslonej grupy nadawcow. Przy 
tak postwionym problemie oczywistym jest ze istnieje relacja miedzy 
nadawca a odbiorca, oczywistym wiec jest ze releacje ta trzeba 
odzwierciedlic. Przy zejsciu do poziomu implemntacji pojawi sie jawne 
lub niejawne referencjonowanie obiektu odbiorcy przez obiekt nadawcy, 
czy to przez dodanie _prywatnego_ atrybutu, czy tez przez wprowadzenie 
mapowanie czy tez przez inne mechanizmy. Jezeli Pan nadal twierdzi ze 
tak byc nie musi to poprosilbym o pokazanie prostej implementacji.

-- 
a1 (Bartek Janusz) arcone1 gmail com

Obserwując rozwój dyskusji poczuwam się do obowiązku szerszego opisania 
mojego stanowiska, które w międzyczasie stało się terenem spekulacji i 
domysłów :-)

Robię to przewrotnie w historycznie najstarszej gałęzi tego wątku, 
częściowo z własnego widzimisię, a po części też ze względu na bliskość 
źródła nieporozumień.

>>Czy nie byłoby lepiej, gdyby to użytkownik operował bezpośrednio na 
>>Session? Przedstawiony schemat, który często napotykam, pachnie mi 
>>antywzorcem Man-In-The-Middle.
> 
> 
> To zależy. W przypadku Javy pewnie tak (bo nie da się zabronić dostępu do
> zewnętrznie zdefiniowanej klasy). W przypadku C++ nie jest to już takie
> oczywiste, bo można zrobić klasę taką, do której metod (w tym konstruktora) ma
> dostęp tylko inna (wskazana) klasa. W takim przypadku ktoś "z zewnątrz" mógłby
> wszelkie operacje wykonać tylko za pośrednictwem managera.

W charakterze dygresji technicznej: w Javie też się tak da, umieszczając 
managera i Session w tym samym pakiecie (namespace) i deklarując 
wszystkie składowe klasy (w tym konstruktor) jako widzialne tylko w 
obrębie pakietu (tzw. widoczność domyślna). Istnieje też w Javie 
możliwość zadeklarowania całej klasy jako widzialnej jedynie w obrębie 
pakietu, ale w tym wypadku Session nie byłoby to sensowne (występuje 
jako parametr publicznej metody managera).

> Można też stosować taką technikę, że to, co podajesz do metody managera (tu
> podajesz Session), nie będzie bezpośrednim wskazaniem na obiekt, tylko jego
> identyfikatorem. Czyli z zewnątrz można tylko menedżerowi powiedzieć, o jaki
> obiekt nam chodzi, ale nie można na nim samodzielnie wykonywać żadnych
> operacji.

Faktycznie można, ale nie ta ścieżka dyskusji jest dla mnie najbardziej 
interesująca, więc pozwolę ją sobie pominąć.

> Przykład z twojej strony nie ma za wiele sensu, bo problem nie polega na
> sposobie zaimplementowania całego mechanizmu, lecz na logice całego "designu".
> Rozstrząsanie, czy setDeactivated powinno być metodą managera, jest zupełnie
> bezprzedmiotowe - zapytaj raczej, dlaczego ktoś z zewnątrz miałby mieć
> możliwość deaktywacji sesji, po co mu to, a w związku z tym, czy sposób
> operowania menedżerem, jaki opracowałeś, tworząc jego interfejs, przewiduje
> deaktywację sesji z zewnątrz, czy nie.

Dobre pytanie - być może najsensowniejszym rozwiązaniem byłoby to, gdyby 
sesja sama się deaktywowała w określonych okolicznościach. Przyjmijmy 
jednak, że możliwość deaktywacji sesji z zewnątrz jest udostępniona na 
potrzeby administratora systemu, który lubi od czasu do czasu się 
powtrącać i coś skasować względnie zdeaktywować.

> Jeśli implementacja polega na przekierowaniu do metody sesji, to być może i
> nie ma to za wiele sensu. Ale jeśli obiekt sesji dostaje poza tym kopa ze
> zbiornika sesji, to już nie wydaje się być to takie bez sensu.

a dla mnie nadal takie się wydaje, szczegóły niżej

>>Wydaje mi się, że jeśli nawet taki manager chce koniecznie kontrolować 
>>zmiany w swoich dzieciach, to lepszy do tego jest wzorzec Observer, 
> 
> Observer? Z choinki się urwałeś? 

Observer, lecz kwestia mojego domniemanego urwania się z choinki jest 
przedmiotem nieustannych sporów i kontrowersji, dlatego wolałbym, żeby 
głos w tej sprawie zajął ktoś bardziej kompetentny od mojej skromnej osoby.

> To jest zupełnie inny temat, inna kategoria.
> Kto miałby być observerem kogo i - przede wszystkim - jakie stany cząstkowe
> danego obiektu miałyby być "obserwowane" przez obserwatorów? Spróbuj
> odpowiedzieć na powyższe pytanie, to będziesz wiedział, czy Observer się
> nadaje. Hint:
> 
> http://sern.ucalgary.ca/courses/SENG/609.04/W98/lamsh/observerLib.html

Obserwatorem miałby byc manager, obiektami obserwowanymi - Sessions. 
Szczegóły niżej.

Dla mnie najważniejsze we wzorcu Observer jest zdarzeniowość. Wcale nie 
najważniejsza jest dla mnie synchronizacja jakiś stanów - dopuszczam 
nawet Observera w przypadku obiektów bezstanowych. Jeśli takie 
pojmowanie tego wzorca utrudnia Ci analizę omawianego modelu, to możemy 
umówić się, że chodzi mi o zdarzeniowość - jeden obiekt rejestruje się w 
"nadajniku" zdarzeń jako odbiorca określonego typu zdarzeń - ten 
odbiorca implementuje ustalony interface. Następnie "nadajnik" 
powiadamia wszystkich zarejestrowanych odbiorców o interesujących ich 
zdarzeniach, kiedy one wystąpią. Kod obsługi danego zdarzenia jest czymś 
właściwym tylko dla odbiornika zdarzeń i nie musi ograniczać się do 
aktualizowania swojego stanu.

Jak widziałbym to w kodzie (pewne słowa kluczowe dodałem dla ich 
większej czytelności dla osób nie programujących na codzień w Javie):

public interface SessionObserver {
// interface to inaczej klasa czysto abstrakcyjna w C++

	public abstract void sessionDeactivated(Session deactivatedOne);

	// inne metody powiadomień
}

public class Session {
	List<SessionObserver> observers;

	// metody do rejestrowania nowych obserwatorów

	public void deactivate() {
		// zmiana swojego stanu
		for (SessionObserver observer: observers) {
			observer.sessionDeactivated(this);
		}
	}
}

public class SessionManager implements SessionObserver {

	// w którejś z metod tworzenia Session
	// session.addObserver(this);

	List<Session> activeSessions;

	public void sessionDeactivated(Session deactivatedOne) {
		activeSessions.remove(deactivatedOne);
	}
}

Tak to by wyglądało w dużym uproszczeniu. Mam nadzieję, że ten przykład, 
choć niekompletny, wyjaśni w większym stopniu co miałem na myśli.

Przemysław Pokrywka

Dnia Thu, 13 Jul 2006 22:20:23 +0200, Przemek Pokrywka skrobie:
> >>Czy nie byłoby lepiej, gdyby to użytkownik operował bezpośrednio na 
> >>Session? Przedstawiony schemat, który często napotykam, pachnie mi 
> >>antywzorcem Man-In-The-Middle.
> > 
> > 
> > To zależy. W przypadku Javy pewnie tak (bo nie da się zabronić dostępu do
> > zewnętrznie zdefiniowanej klasy). W przypadku C++ nie jest to już takie
> > oczywiste, bo można zrobić klasę taką, do której metod (w tym konstruktora) ma
> > dostęp tylko inna (wskazana) klasa. W takim przypadku ktoś "z zewnątrz" mógłby
> > wszelkie operacje wykonać tylko za pośrednictwem managera.

> W charakterze dygresji technicznej: w Javie też się tak da, umieszczając 
> managera i Session w tym samym pakiecie (namespace) i deklarując 
> wszystkie składowe klasy (w tym konstruktor) jako widzialne tylko w 
> obrębie pakietu (tzw. widoczność domyślna).

Śmiech na sali, też mi ochrona :). To nie przeczy wcale stwierdzeniu,
że w Javie nie da się zabronić dostępu do zewnętrznie zdefiniowanej klasy.
Dostęp w obrębie pakietu co najwyżej go tylko utrudnia, bo w tym celu muszę
sobie zdefiniować klasę w tym samym pakiecie, co nie jest przecież niemożliwe.

Nawiasem mówiąc, podobna sprawa istnieje w Tcl - tam przestrzenie nazw
domyślnie są całkowicie prywatne i można tylko udostępnić do eksportu
określone symbole (tzn. robiąc namespace import * wciąga się nie wszystkie
nazwy, ale te, które zostały zdefiniowane jako namespace export). Ale nikt mi
nie zabroni w zupełnie innym miejscu użyć sobie tej samej przestrzeni nazw.

Z uwagi zapewne na tą iluzoryczną ochronę, w C++ zrezygnowano z jakiegokolwiek
sterowania dostępem wewnątrz przestrzeni nazw.

> Istnieje też w Javie 
> możliwość zadeklarowania całej klasy jako widzialnej jedynie w obrębie 
> pakietu,

Owszem, tak jest zresztą domyślnie.

> ale w tym wypadku Session nie byłoby to sensowne (występuje 
> jako parametr publicznej metody managera).

A może właśnie niekoniecznie to tak powinno być! Może powinieneś operować
jakąś klasą bazową dla Session, która jest dostępna publicznie, ale samą klasą
Session może operować tylko manager? Tak, żeby ta klasa, która jest publiczna
dawała tylko możliwość identyfikowania sesji i pokazywania managerowi, o jaką
sesję chodzi - ale operacje na niej może już wykonać tylko manager?

> > Można też stosować taką technikę, że to, co podajesz do metody managera (tu
> > podajesz Session), nie będzie bezpośrednim wskazaniem na obiekt, tylko jego
> > identyfikatorem. Czyli z zewnątrz można tylko menedżerowi powiedzieć, o jaki
> > obiekt nam chodzi, ale nie można na nim samodzielnie wykonywać żadnych
> > operacji.

> Faktycznie można, ale nie ta ścieżka dyskusji jest dla mnie najbardziej 
> interesująca, więc pozwolę ją sobie pominąć.

Mięczak lol ;)

> > Przykład z twojej strony nie ma za wiele sensu, bo problem nie polega na
> > sposobie zaimplementowania całego mechanizmu, lecz na logice całego "designu".
> > Rozstrząsanie, czy setDeactivated powinno być metodą managera, jest zupełnie
> > bezprzedmiotowe - zapytaj raczej, dlaczego ktoś z zewnątrz miałby mieć
> > możliwość deaktywacji sesji, po co mu to, a w związku z tym, czy sposób
> > operowania menedżerem, jaki opracowałeś, tworząc jego interfejs, przewiduje
> > deaktywację sesji z zewnątrz, czy nie.

> Dobre pytanie - być może najsensowniejszym rozwiązaniem byłoby to, gdyby 
> sesja sama się deaktywowała w określonych okolicznościach.

Do wykonania tego publiczność tej operacji nie jest potrzebna, to chyba
oczywiste.

> Przyjmijmy 
> jednak, że możliwość deaktywacji sesji z zewnątrz jest udostępniona na 
> potrzeby administratora systemu, który lubi od czasu do czasu się 
> powtrącać i coś skasować względnie zdeaktywować.

No to dobra - a teraz kolejne pytanie: co to jest deaktywacja sesji i jakie
konsekwencje ma ona dla całego systemu? Innymi słowy - tu już wtrącam znów z
teorią stanów cząstkowych - jakie operacje trzeba wykonać w celu deaktywacji
sesji, by pozostawić cały system w stanie stabilnym?

Skąd pytanie: załóżmy (bo być może tak jest), że manager zarządza sesjami i
manager musi w jakiś sposób odnotować w swoich zasobach, że dana sesja została
zdezaktywowana, w związku z czym musi, np., usunąć ją z jakiegoś zbiornika, a
może ma jakieś własne dodatkowe dane opisujące sesję i coś w nich trzeba w
związku z tym zmienić. W związku z tym, operacja deaktywacji, jaka może być
zdefiniowana wyłącznie jako metoda Session, będzie wykonywać deaktywację tylko
z poziomu samej siebie, ale nie z poziomu managera. Ponieważ stan w managerze
musi być w związku z deaktywacją zsynchronizowany ze stanem sesji, więc
wykonanie operacji na samej sesji doprowadza system do niestabilnego stanu (bo
sesja zdechła, a manager sobie tego odpowiednio nie odnotował).

Jeśli tak jest, to w takim razie deaktywacja sesji z zewnątrz powinna być w
jakiś sposób uniemożliwiona i możliwa do wykonania tylko przez managera. A
manager wykona wtedy na danej sesji deaktywację, jako część operacji (po tej
operacji, a przed pozostałymi operacjami, następuje tzw. chwilowe zachwianie
stabilności stanu - jest to bardzo podobne np. do dodawania dwóch liczb
zespolonych: dodałeś już część rzeczywistą, a jeszcze nie dodałeś części
urojonej). A potem wykona odpowiednie aktualizacje w swoich danych w związku z
deaktywacją sesji.

> > Jeśli implementacja polega na przekierowaniu do metody sesji, to być może i
> > nie ma to za wiele sensu. Ale jeśli obiekt sesji dostaje poza tym kopa ze
> > zbiornika sesji, to już nie wydaje się być to takie bez sensu.

> a dla mnie nadal takie się wydaje, szczegóły niżej

Ciekawe ;)

> >>Wydaje mi się, że jeśli nawet taki manager chce koniecznie kontrolować 
> >>zmiany w swoich dzieciach, to lepszy do tego jest wzorzec Observer, 
> > 
> > Observer? Z choinki się urwałeś? 

> Observer, lecz kwestia mojego domniemanego urwania się z choinki jest 
> przedmiotem nieustannych sporów i kontrowersji, dlatego wolałbym, żeby 
> głos w tej sprawie zajął ktoś bardziej kompetentny od mojej skromnej osoby.

To będziesz musiał poszerzyć znacznie zakres poszukiwań poza tę grupę, bo tu
ci sukcesu na tym polu nie wróżę.

> > To jest zupełnie inny temat, inna kategoria.
> > Kto miałby być observerem kogo i - przede wszystkim - jakie stany cząstkowe
> > danego obiektu miałyby być "obserwowane" przez obserwatorów? Spróbuj
> > odpowiedzieć na powyższe pytanie, to będziesz wiedział, czy Observer się
> > nadaje. Hint:
> > 
> > http://sern.ucalgary.ca/courses/SENG/609.04/W98/lamsh/observerLib.html

> Obserwatorem miałby byc manager, obiektami obserwowanymi - Sessions. 
> Szczegóły niżej.

> Dla mnie najważniejsze we wzorcu Observer jest zdarzeniowość. Wcale nie 
> najważniejsza jest dla mnie synchronizacja jakiś stanów - dopuszczam 
> nawet Observera w przypadku obiektów bezstanowych.

Tak, zgadza się - chociaż wcale nie powiedziałem, że synchronizacja stanu
polega na tym, że obiekt A czyta jakiś stan cząstkowy obiektu B i na jego
podstawie zmienia jakiś stan cząstkowy u siebie. Zdarzenie wywołuję akcję, a
jej konsekwencje mogą mieć wielorakie znaczenie.

> Jeśli takie 
> pojmowanie tego wzorca utrudnia Ci analizę omawianego modelu, to możemy 
> umówić się, że chodzi mi o zdarzeniowość - jeden obiekt rejestruje się w 
> "nadajniku" zdarzeń jako odbiorca określonego typu zdarzeń - ten 
> odbiorca implementuje ustalony interface. Następnie "nadajnik" 
> powiadamia wszystkich zarejestrowanych odbiorców o interesujących ich 
> zdarzeniach, kiedy one wystąpią. Kod obsługi danego zdarzenia jest czymś 
> właściwym tylko dla odbiornika zdarzeń i nie musi ograniczać się do 
> aktualizowania swojego stanu.

Załóżmy.

> Jak widziałbym to w kodzie (pewne słowa kluczowe dodałem dla ich 
> większej czytelności dla osób nie programujących na codzień w Javie):

> public interface SessionObserver {
> // interface to inaczej klasa czysto abstrakcyjna w C++

>         public abstract void sessionDeactivated(Session deactivatedOne);

>         // inne metody powiadomień
> }

> public class Session {
>         List<SessionObserver> observers;

>         // metody do rejestrowania nowych obserwatorów

>         public void deactivate() {
>                 // zmiana swojego stanu
>                 for (SessionObserver observer: observers) {
>                         observer.sessionDeactivated(this);
>                 }
>         }
> }

> public class SessionManager implements SessionObserver {

>         // w którejś z metod tworzenia Session
>         // session.addObserver(this);

>         List<Session> activeSessions;

>         public void sessionDeactivated(Session deactivatedOne) {
>                 activeSessions.remove(deactivatedOne);
>         }
> }

> Tak to by wyglądało w dużym uproszczeniu. Mam nadzieję, że ten przykład, 
> choć niekompletny, wyjaśni w większym stopniu co miałem na myśli.

Taaa... pomarudził, że to "nie jest tylko taka synchronizacja stanu", po czym
pokazał przykład klasycznej synchronizacji stanu ;) lol

Ja wiedziałem od początku, co masz na myśli, i dlatego pokazanie przez ciebie
przykładu nie zmieniło mojego zdania, że jest to totalny bezsens.

Zauważ, że hierarchia jest tutaj tak, czy siak, narzucona przez sam fakt, że
sesje mają swojego managera. Jeśli to ma być manager, który zarządza sesją, to
zarządza również wszelkimi przejawami ich działania: tworzy sesje, zamyka
sesje, więc nie widzę powodu, dla którego nie miałby również mieć wyłaczność
na zarządzanie obiektami sesji. Obiekt sesji może mieć publiczny interfejs,
który pozwalałby jej na różne operacje, ale które sa charakterystyczne dla
obiektów "aktywnych", natomiast nie takie, które kończą jej życie.

Hierarchia taka powoduje, że naturalnym podejściem staje się dzielenie
operacji na poziomy, przy czym operacje na niższym poziomie wykonują te
obiekty stojące niżej w hierarchii, a te na wyższym poziomie - wyżej. Manager
zatem ma dostęp do tego, co robi sesja, i jest w stanie sam na tej sesji różne
rzeczy wykonać, natomiast operacje samej sesji mają dotyczyć stanu tylko i
wyłącznie jej. Inaczej mówiąc, sesja operuje tylko na swoim własnym stanie, a
manager operuje na własnym stanie oraz na stanie sesji. Taki model narzuca
sama hierarchia.

Dlatego zupełnie naturalną rzeczą jest, że sesja ma swoją metodę od
dezaktywacji, która wykonuje określone czynności wyłącznie w ramach sesji,
a manager w celu zdezaktywowania określonej sesji, każe sesji się najpierw
zamknąć, a następnie usuwa sesję. Manager nie potrzebuje, żeby sesja go o
czymkolwiek powiadamiała - sam z założenia rządzi sesjami i każe sesjom tylko
wykonać określone czynności.

Natomiast to, co ty tutaj próbujesz zrobić, to postawić managera sesji jako
kontraktora, czy współpracownika sesji, bo w określonych sytuacjach sesja
staje się nadzorcą dla managera. Tak niestety jest, również w technologii
sygnałów i slotów, że obiekt nadajnika staje się nadzorcą (nadzorcą
specjalizowanym oczywiście, czyli nadzorcą tylko w pewnym, zawężonym obszarze
działań) dla obiektu odbiornika (co nie staje w sprzeczności z faktem, że
obiekty mogą być takimi relacjami związane w obie strony).

A jak będziesz tworzył nową sesję, to jak to zrobisz? Będziesz wołał
konstruktor Session podając jej managera, jako argument? A Sesja wywoła
manager.addSession( this )?

Takie postawienie sprawy jest o tyle bez sensu, że manager w takim wypadku
właściwie do niczego nie służy, poza tym, że zawiera listę sesji. Taki projekt
jest całkowicie na bakier z hierarchizacją, która stanowi ważną część
programowania obiektowego. Zależności zarówno stanów, jak i zachowania są
tutaj poplątane, odmiennie niż w strukturze hierarchicznej. Jest to najgorszy
możliwy sposób wykorzystywania wiedzy książkowej, bo nie dość, że łamie to
wszelkie ugruntowane standardy programowania obiektowego, to jeszcze stanowi
swoisty przerost formy nad treścią. Dlaczego?

Dlatego, że jeśli przyjmiemy już coś takiego, że manager nie rządzi sesjami,
tylko sesje go powiadajamiają o określonych działaniach, to PO JAKI CHUJ JEST
NAM TEN MANAGER? Zrób po prostu listę sesji jako pole statyczne klasy Session!
Odpada ci pisanie dodatkowej klasy SessionManager, odpada ci też robienie
jakichś wymyślnych interfejsów Observera. A jak potrzebujesz dostępu, to sobie
zapisz gdzieś referencję do tego pola i wszystko jest na miejscu.

Masz zatem dwie możliwości: albo robisz to na zasadzie, że sesja podlega
managerowi i manager wyłącznie wykonuje wszelkie operacje, które zmieniają
"liczebność sesji", albo manager jest ci całkowicie zbędny. Zastosowanie
Observera mniej więcej tak ci polepszy projekt, jak podświetlane podwozie w
samochodzie polepszy ci moc silnika.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ 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 napisał(a):
> Dnia Thu, 13 Jul 2006 22:20:23 +0200, Przemek Pokrywka skrobie:
> 
>>>>Czy nie byłoby lepiej, gdyby to użytkownik operował bezpośrednio na 
>>>>Session? Przedstawiony schemat, który często napotykam, pachnie mi 
>>>>antywzorcem Man-In-The-Middle.
>>>
>>>To zależy. W przypadku Javy pewnie tak (bo nie da się zabronić dostępu do
>>>zewnętrznie zdefiniowanej klasy). W przypadku C++ nie jest to już takie
>>>oczywiste, bo można zrobić klasę taką, do której metod (w tym konstruktora) ma
>>>dostęp tylko inna (wskazana) klasa. W takim przypadku ktoś "z zewnątrz" mógłby
>>>wszelkie operacje wykonać tylko za pośrednictwem managera.
> 
>>W charakterze dygresji technicznej: w Javie też się tak da, umieszczając 
>>managera i Session w tym samym pakiecie (namespace) i deklarując 
>>wszystkie składowe klasy (w tym konstruktor) jako widzialne tylko w 
>>obrębie pakietu (tzw. widoczność domyślna).
> 
> Śmiech na sali, też mi ochrona :). To nie przeczy wcale stwierdzeniu,
> że w Javie nie da się zabronić dostępu do zewnętrznie zdefiniowanej klasy.
> Dostęp w obrębie pakietu co najwyżej go tylko utrudnia, bo w tym celu muszę
> sobie zdefiniować klasę w tym samym pakiecie, co nie jest przecież niemożliwe.
> 
> Nawiasem mówiąc, podobna sprawa istnieje w Tcl - tam przestrzenie nazw
> domyślnie są całkowicie prywatne i można tylko udostępnić do eksportu
> określone symbole (tzn. robiąc namespace import * wciąga się nie wszystkie
> nazwy, ale te, które zostały zdefiniowane jako namespace export). Ale nikt mi
> nie zabroni w zupełnie innym miejscu użyć sobie tej samej przestrzeni nazw.

Oczywiście, że nie, ale skoro już używasz takiej samej przestrzeni nazw 
jedynie w celu uzyskania dostępu do elementów o ograniczonej 
widoczności, to lepiej orientuj się w tym co robisz, bo wg powszechnie 
uznanej wśród programistór Javy konwencji autor nie gwarantuje Ci wtedy 
poprawnego działania Twojej aplikacji.

Uważam, że przestrzeganie takiej konwencji, wspierane cechą języka jest 
w większości przypadków znacznie lepszym rozwiązaniem, niż wybór 
pomiędzy dwoma skrajnościami oferowany przez C++: swobodny dostęp 
niezależny od namespace albo friend, wymuszający na chronionej klasie 
posiadanie wiedzy o swoim kręgu przyjaciół. Swoją drogą, brak 
konstrukcji friend jeszcze nigdy mi jakoś w Javie nie przeszkodził i nie 
słyszałem też żeby komuś innemu (nie widziałem zgłoszonych w tej sprawie 
Java Specification Requests).

>>ale w tym wypadku Session nie byłoby to sensowne (występuje 
>>jako parametr publicznej metody managera).
 >
> A może właśnie niekoniecznie to tak powinno być! Może powinieneś operować
> jakąś klasą bazową dla Session, która jest dostępna publicznie, ale samą klasą
> Session może operować tylko manager? Tak, żeby ta klasa, która jest publiczna
> dawała tylko możliwość identyfikowania sesji i pokazywania managerowi, o jaką
> sesję chodzi - ale operacje na niej może już wykonać tylko manager?
 >
>>>Można też stosować taką technikę, że to, co podajesz do metody managera (tu
>>>podajesz Session), nie będzie bezpośrednim wskazaniem na obiekt, tylko jego
>>>identyfikatorem. Czyli z zewnątrz można tylko menedżerowi powiedzieć, o jaki
>>>obiekt nam chodzi, ale nie można na nim samodzielnie wykonywać żadnych
>>>operacji.
> 
>>Faktycznie można, ale nie ta ścieżka dyskusji jest dla mnie najbardziej 
>>interesująca, więc pozwolę ją sobie pominąć.
> 
> Mięczak lol ;)

Jednym słowem bardzo chesz o tym porozmawiać :-). Najchętniej uczyniłbym 
to w oddzielnym wątku (temat "opaque identifiers"), bo w tym jest już 
poruszona wystarczająca liczba problemów. Sądzę, że jak skrytykuję Twój 
pomysł, to będziesz go zaciekle bronił :-) Jeśli tak, to bardzo Cię 
proszę, w oddzielnym wątku.

W skrócie moja niechęć do tego rozwiązania bierze się stąd, że kod 
kliencki w moim przekonaniu nie powinien być zmuszany do operowania 
większą liczbą obiektów, niż to konieczne. Jeśli _może_ operować Sesją 
(albo jednym z interfejsów Sesji, jeśli konieczne jest zabronienie 
klientom dostępu do określonych metod tej klasy), to po co kazać mu 
operować na IdentyfikatorzeSesji oraz na MenedżerzeSesji (zakładam, że 
mówimy o kliencie, który tę Sesję skądś już ma - nie musiał jej wyszukać 
w SessionMenedżerze)?
Drugi powód to moja osobista preferencja - od czasu, gdy zacząłem 
programować obiektowo, przedkładam wyrażenia typu obiekt.operacja() nad 
algorytm(struktura_danych), a metoda deactivate(Session) klasy 
SessionManager przypomina mi to ostatnie wywołanie. Nie lubię 
zredukowanych obiektów typu "opaque identifier", Transfer Objects, albo 
rozpowszechnionych w świecie Javy tzw. "JavaBeans" - JavaBeans 
zredukowanych do roli struktur danych, bez ciekawego zachowania. 
Programować przy pomocy "opaque identifiers" można bez żadnych obiektów.

>>Przyjmijmy 
>>jednak, że możliwość deaktywacji sesji z zewnątrz jest udostępniona na 
>>potrzeby administratora systemu, który lubi od czasu do czasu się 
>>powtrącać i coś skasować względnie zdeaktywować.
> 
> 
> No to dobra - a teraz kolejne pytanie: co to jest deaktywacja sesji i jakie
> konsekwencje ma ona dla całego systemu? Innymi słowy - tu już wtrącam znów z
> teorią stanów cząstkowych - jakie operacje trzeba wykonać w celu deaktywacji
> sesji, by pozostawić cały system w stanie stabilnym?
> 
> Skąd pytanie: załóżmy (bo być może tak jest), że manager zarządza sesjami i
> manager musi w jakiś sposób odnotować w swoich zasobach, że dana sesja została
> zdezaktywowana, w związku z czym musi, np., usunąć ją z jakiegoś zbiornika, a
> może ma jakieś własne dodatkowe dane opisujące sesję i coś w nich trzeba w
> związku z tym zmienić. W związku z tym, operacja deaktywacji, jaka może być
> zdefiniowana wyłącznie jako metoda Session, będzie wykonywać deaktywację tylko
> z poziomu samej siebie, ale nie z poziomu managera. Ponieważ stan w managerze
> musi być w związku z deaktywacją zsynchronizowany ze stanem sesji, więc
> wykonanie operacji na samej sesji doprowadza system do niestabilnego stanu (bo
> sesja zdechła, a manager sobie tego odpowiednio nie odnotował).

Jest dokładnie tak, jak piszesz. Jednak Twój wniosek, że "deaktywacja 
sesji z zewnątrz powinna być w jakiś sposób uniemożliwiona i możliwa do 
wykonania tylko przez managera" uważam za błędny. Ta deaktywacja _może_ 
być zrealizowana tak, jak mówisz, ale _lepszym_ rozwiązaniem jest 
zdaniem użycie w miarę ogólnego schematu powiadomień (żeby nie użyć 
słowa "Observer") do zadbania o to, by menedżer miał aktualny stan.
Dlaczego lepszym?
Lepszym dlatego, że klient, który posiada referencję do Sesji nie 
potrzebuje referencji do jej menedżera, żeby ją zdeaktywować. Co więcej, 
   jeśli tę Sesję dostał od innego obiektu, może nawet nie wiedzieć, że 
coś takiego, jak menedżer sesji istnieje!
Drugim powodem jest ważna zasada programowania obiektowego - Singular 
Responsibility Principle. Menedżer skupia się na swoim podstawowym 
zadaniu - wyszukiwaniu sesji (oczywiście można teraz słusznie 
zakwestionować jego nazwę i to będzie krok w dobrym kierunku), Sesja 
skupia się na swoich zadaniach. W nieszczęsnych programach, w których 
zdarzało mi się widzieć dyskutowany antywzorzec, obiekt Menedżera 
dublował metody Sesji 1:1, nawet wtedy, gdy nie potrzebował aktualizować 
swojego stanu przy zmianie danej Sesji - bo niby dlaczego miał dublować 
je wybiórczo? Prowadziło to do absurdalnego wręcz rozrostu kodu różnej 
maści Menedżerów, które w swojej większej części grały po prostu rolę 
Man in The Middle.

Co do wspomnianej "hierarchizacji", to widzę wartość w dzieleniu 
aplikacji na logiczne "poziomy" i konsekwentnym stosowaniu reguły, żeby 
kod z jednego poziomu operował na identycznym poziomie abstrakcji (np. 
żeby operowanie na Sesjach nie mieszało się z obsługą wyjątków typu 
FileNotFoundException). Jednak stosowanie hierarchii potrafi też 
wypaczać się w potworki w rodzaju opisanych Menedżerów, na co trzeba 
zwracać uwagę.

> Zauważ, że hierarchia jest tutaj tak, czy siak, narzucona przez sam fakt, że
> sesje mają swojego managera. Jeśli to ma być manager, który zarządza sesją, to
> zarządza również wszelkimi przejawami ich działania: tworzy sesje, zamyka
> sesje, więc nie widzę powodu, dla którego nie miałby również mieć wyłaczność
> na zarządzanie obiektami sesji. Obiekt sesji może mieć publiczny interfejs,
> który pozwalałby jej na różne operacje, ale które sa charakterystyczne dla
> obiektów "aktywnych", natomiast nie takie, które kończą jej życie.
> 
> Hierarchia taka powoduje, że naturalnym podejściem staje się dzielenie
> operacji na poziomy, przy czym operacje na niższym poziomie wykonują te
> obiekty stojące niżej w hierarchii, a te na wyższym poziomie - wyżej. Manager
> zatem ma dostęp do tego, co robi sesja, i jest w stanie sam na tej sesji różne
> rzeczy wykonać, natomiast operacje samej sesji mają dotyczyć stanu tylko i
> wyłącznie jej. Inaczej mówiąc, sesja operuje tylko na swoim własnym stanie, a
> manager operuje na własnym stanie oraz na stanie sesji. Taki model narzuca
> sama hierarchia.
> 
> Dlatego zupełnie naturalną rzeczą jest, że sesja ma swoją metodę od
> dezaktywacji, która wykonuje określone czynności wyłącznie w ramach sesji,
> a manager w celu zdezaktywowania określonej sesji, każe sesji się najpierw
> zamknąć, a następnie usuwa sesję. Manager nie potrzebuje, żeby sesja go o
> czymkolwiek powiadamiała - sam z założenia rządzi sesjami i każe sesjom tylko
> wykonać określone czynności.

Być może popularną i wydającą się naturalną (ze względu na prostotę 
implementacji dla programisty), ale, co jest od tego ważniejsze - gorszą 
z punktu widzenia programisty-klienta. A jak wiadomo to "klient nasz 
pan". Dlaczego gorszą, opisałem wyżej.

> Natomiast to, co ty tutaj próbujesz zrobić, to postawić managera sesji jako
> kontraktora, czy współpracownika sesji, bo w określonych sytuacjach sesja
> staje się nadzorcą dla managera. Tak niestety jest, również w technologii
> sygnałów i slotów, że obiekt nadajnika staje się nadzorcą (nadzorcą
> specjalizowanym oczywiście, czyli nadzorcą tylko w pewnym, zawężonym obszarze
> działań) dla obiektu odbiornika (co nie staje w sprzeczności z faktem, że
> obiekty mogą być takimi relacjami związane w obie strony).

Niestety?? To raczej dobrze! Po to odbiorca zdarzeń się rejestruje w 
nadajniku, żeby ten ostatni go poinformował o pewnych zdarzeniach. Taki 
układ jest najczytelniejszy: SessionManager troszczy się o aktualność 
swojego stanu, więc korzysta z tego, że Sesje rozgłaszają zmiany swoich 
stanów i przy pierwszej nadarzającej się okazji (najczęściej konstrukcja 
Sesji) prosi Sesję, żeby jemu też dała znać o swojej deaktywacji. Tak 
więc mimo, że aktualizacja stanu SessionManagera odbywa się poprzez 
Sesję, to dzieje się tak na wyraźne żądanie SessionManagera, zatem to on 
kontroluje sytuację, a nie na odwrót. Sesja sama nie przypisze sobie 
żadnego SessionManagera (poza tym żeby to zrobić, to musiałaby mieć do 
niego jakąś referencję - a ja nie zakładam nawet tego, że ona wie 
_cokolwiek_ na temat istnienia SessionManagerów).
Manager, jeśli miałby nawet potrzebę _zablokowania_ niektórych zmian w 
Sesji, mógłby się zarejestrować na odbiór pewnego zdarzenia, ogłaszanego 
_przed_ wykonaniem pewnej akcji (patrz constrained properties w 
specyfikacji JavaBeans).

> A jak będziesz tworzył nową sesję, to jak to zrobisz? Będziesz wołał
> konstruktor Session podając jej managera, jako argument? A Sesja wywoła
> manager.addSession( this )?

Zapewne tworzenie Sesji będzie odbywać się w SessionManagerze. Zatem tuż 
po jej stworzeniu SessionManager zarejestruje się w tej Sesji jako 
obiekt zainteresowany jej zmianami 
newSession.addStateChangeObserver(this). Sesja nie będzie nic wywoływać 
na swoich obserwatorach dopóki nie zmieni się jej stan. Natomiast 
SessionManager, świadomy początkowego stanu Sesji, w chwili tworzenia 
jej instancji zaktualizuje swój stan addSession(newSession).

> Takie postawienie sprawy jest o tyle bez sensu, że manager w takim wypadku
> właściwie do niczego nie służy, poza tym, że zawiera listę sesji. 

Lista sesji to bardzo ograniczone ujęcie i było świadomym uproszczeniem 
na użytek przykładu - poza nią manager może zawierać listę sesji 
aktywnych, listę sesji rozpoczętych w ostatniej godzinie, tak jak baza 
danych zawiera indeksy dla danej tabeli w celu szybszego wyszukiwania 
rekordów. Tak więc - zawiera listę sesji, ale prywatną i udostępnia 
szereg metod służących do wyszukiwania sesji.

Mam nadzieję, że teraz już widać, że taki manager do czegoś służy?
Co do jego nazwy, to już wspominałem, że mogłaby być lepsza - obecną 
stosuję wyłącznie z powodów historycznych - taką widziałem w kilku 
projektach.

> Taki projekt
> jest całkowicie na bakier z hierarchizacją, która stanowi ważną część
> programowania obiektowego. 

Programowania to być może tak, bo raczej nie obiektowego w 
szczególności. Na bakier może być poza tym jedynie z hierarchizacją w 
pewnym szczególnym, wąskim rozumieniu, bo jak wykazałem wyżej, kontrola 
pozostaje w gestii managera, jedynie w mniej bezpośredni sposób.

Dla mnie zresztą mógłby być na bakier z hierarchizacją, tak jak z 
wieloma innymi *-zacjami, jeśli tylko ostateczna jakość API 
_z_punktu_widzenia_klienta_ będzie przez to lepsza. Zastosowanie się w 
tym przypadku do zasad tak pojmowanej "hierarchizacji" bardzo dobrze 
pasuje do słów Adama o tryumfie technikaliów nad rzeczywistością, bo 
bardziej liczą się jakieś tam szczegóły wewnętrznej architektury, niż 
faktyczna użyteczność dla klientów.

> Zależności zarówno stanów, jak i zachowania są
> tutaj poplątane, odmiennie niż w strukturze hierarchicznej. 

A tak - te zależności są odmienne i to bardzo, ale jeśli połapanie się w 
nich stanowi dla Ciebie problem, to już raczej wyłącznie Twoja sprawa.

> Jest to najgorszy
> możliwy sposób wykorzystywania wiedzy książkowej, bo nie dość, że łamie to
> wszelkie ugruntowane standardy programowania obiektowego, 

jak "hierarchizacja"? :-) Pokaż mi, co to za ugruntowany standard 
programowania obiektowego i jakie inne "wszelkie" równie mocno 
ugruntowane standardy mój sposób łamie

> to jeszcze stanowi
> swoisty przerost formy nad treścią. Dlaczego?

o proszę :-)

> Dlatego, że jeśli przyjmiemy już coś takiego, że manager nie rządzi sesjami,
> tylko sesje go powiadajamiają o określonych działaniach, to PO JAKI CHUJ JEST
> NAM TEN MANAGER? 

Koledze nerwy już puszczają od takich herezji :-)
Ale gwoli sprawiedliwości dodam, że część zbulwersowania ma prawo 
wynikać z nazwy "manager", która jest - do omawianego zakresu 
odpowiedzialności - nieadekwatna.

> Zrób po prostu listę sesji jako pole statyczne klasy Session!

A to Ci dopiero pomysł, nie ma co! Wprowadzajmy więcej statycznych 
elementów, co tam - garść singletonów tu i ówdzie, jeszcze jakaś 
statyczna lista i nasze programy będą tak się nadawać do wykorzystania 
jako samodzielne komponenty (vide mój inny post), jak mało kiedy.
Wybacz, ale konstrukcje typu static już przerabiałem, a z niektórymi z 
nich przyszło mi żyć do tej pory. I wierz mi, nie jest to nic, z czego 
bym się nadzwyczaj cieszył każdego dnia.

> Odpada ci pisanie dodatkowej klasy SessionManager, odpada ci też robienie
> jakichś wymyślnych interfejsów Observera. 

Wymyślnych?? Człowieku, nad jakim oprogramowaniem Ty pracujesz - u mnie 
Observer to chleb powszedni!

> Masz zatem dwie możliwości: albo robisz to na zasadzie, że sesja podlega
> managerowi i manager wyłącznie wykonuje wszelkie operacje, które zmieniają
> "liczebność sesji", 

No to u mnie tak podlega, przez wzorzec Observer

> albo manager jest ci całkowicie zbędny. 

Taak... I dokładam jeszcze kilka singletonów, bo kocham konstrukcję 
static ;-)

Nie rozważaliśmy do tej pory jeszcze jednego aspektu - wiele 
obserwatorów jednej Sesji. Jest dla mnie normalnym scenariuszem, że 
zmianami w sesji zainteresowanych jest w jednym momencie kilku 
obserwatorów naraz - każdy z nich interesujący się odrębnym aspektem tej 
samej Sesji. Rozwiązanie hierarchiczne wypada znacznie gorzej od wzorca 
Observer wg fundamentalnej zasady Open-Closed. W wypadku Observera 
zgodność z tą zasadą otrzymujemy na starcie, w rozwiązaniu 
"hierarchicznym" musimy kombinować.

Reasumując, nic a nic nie przekonałeś mnie do rozwiązania 
"zhierarchizowanego" (którego nie przypisuję wcale Tobie, bo jest 
rozplenione jak chwast po większości oprogramowania obiektowego jakie 
znam - stąd mój post na tą grupę). Chętnie jednak dowiem się, jak 
jeszcze uzasadnisz wyższość bronionego przez Ciebie rozwiązania, bo jak 
na razie nie dowiedziałem się o niczym, o czym nie wiedziałbym wcześniej.

PS. Moje uznanie dla ogromu pracy włożonego w 
http://www.intercon.pl/~sektor/cbx/

Dnia Mon, 17 Jul 2006 21:06:08 +0200, Przemek Pokrywka skrobie:
> > Dostęp w obrębie pakietu co najwyżej go tylko utrudnia, bo w tym celu muszę
> > sobie zdefiniować klasę w tym samym pakiecie, co nie jest przecież niemożliwe.
> > 
> > Nawiasem mówiąc, podobna sprawa istnieje w Tcl - tam przestrzenie nazw
> > domyślnie są całkowicie prywatne i można tylko udostępnić do eksportu
> > określone symbole (tzn. robiąc namespace import * wciąga się nie wszystkie
> > nazwy, ale te, które zostały zdefiniowane jako namespace export). Ale nikt mi
> > nie zabroni w zupełnie innym miejscu użyć sobie tej samej przestrzeni nazw.

> Oczywiście, że nie, ale skoro już używasz takiej samej przestrzeni nazw 
> jedynie w celu uzyskania dostępu do elementów o ograniczonej 
> widoczności, to lepiej orientuj się w tym co robisz, bo wg powszechnie 
> uznanej wśród programistór Javy konwencji autor nie gwarantuje Ci wtedy 
> poprawnego działania Twojej aplikacji.

Jasne. Na dokładnie tej samej zasadzie możesz mówić o dowolnej klasie, która
nie została wymieniona w interfejsie biblioteki. Też jej używać można, ale
lepiej nie.

Ciekawe, że Java jest gloryfikowana jako język, który - w odróżnieniu od C++ -
uniemożliwia ludziom robienie głupot, podczas gdy C++ jedynie je utrudnia, a
czasem i to nie. W tym wypadku okazuje się dokładnie odwrotnie: w C++ możesz
stworzyć klasę, której obiekt będzie miała prawo utworzyć tylko inna klasa
(lub funkcja, lub wybrana metoda wybranej klasy), a w Javie możesz tylko
wrzucić klasę w pakiet i liczyć na to, że użytkownik nie zdefiniuje sobie w
tym samym pakiecie klasy. Ale oczywiście w tym wypadku i tak Java jest lepsza.
;-P

> Uważam, że przestrzeganie takiej konwencji, wspierane cechą języka jest 
> w większości przypadków znacznie lepszym rozwiązaniem, niż wybór 
> pomiędzy dwoma skrajnościami oferowany przez C++: swobodny dostęp 
> niezależny od namespace albo friend, wymuszający na chronionej klasie 
> posiadanie wiedzy o swoim kręgu przyjaciół.

Nie "posiadanie wiedzy o swoim kręgu przyjaciół", tylko nadawanie odpowiednim
elementom programu praw dostępu. To prawo albo dajesz, albo nie. Zresztą nawet
to wielu twórców bibliotek zdaje się olewać: w niektórych bibliotekach boost
na przykład stosuje się przestrzeń nazw 'details', a w niej normalne, nie
chronione niczym, klasy. I to też wystarcza.

> Swoją drogą, brak 
> konstrukcji friend jeszcze nigdy mi jakoś w Javie nie przeszkodził

To o niczym nie świadczy.

> i nie słyszałem też żeby komuś innemu (nie widziałem zgłoszonych w tej
> sprawie Java Specification Requests).

To słabo czytałeś, bo ja widziałem. Nie wiem gdzie jest dokładnie JSR, więc
nie znajdę, ale ktoś mi, być może nawet na tej grupie, rzucał jakiś czas temu
linkiem. Oczywiście - podobnie jak const - dostało status "won't be resolved".

> > A może właśnie niekoniecznie to tak powinno być! Może powinieneś operować
> > jakąś klasą bazową dla Session, która jest dostępna publicznie, ale samą klasą
> > Session może operować tylko manager? Tak, żeby ta klasa, która jest publiczna
> > dawała tylko możliwość identyfikowania sesji i pokazywania managerowi, o jaką
> > sesję chodzi - ale operacje na niej może już wykonać tylko manager?
>  >
> >>>Można też stosować taką technikę, że to, co podajesz do metody managera (tu
> >>>podajesz Session), nie będzie bezpośrednim wskazaniem na obiekt, tylko jego
> >>>identyfikatorem. Czyli z zewnątrz można tylko menedżerowi powiedzieć, o jaki
> >>>obiekt nam chodzi, ale nie można na nim samodzielnie wykonywać żadnych
> >>>operacji.
> > 
> >>Faktycznie można, ale nie ta ścieżka dyskusji jest dla mnie najbardziej 
> >>interesująca, więc pozwolę ją sobie pominąć.
> > 
> > Mięczak lol ;)

> Jednym słowem bardzo chesz o tym porozmawiać :-). Najchętniej uczyniłbym 
> to w oddzielnym wątku (temat "opaque identifiers"), bo w tym jest już 
> poruszona wystarczająca liczba problemów. Sądzę, że jak skrytykuję Twój 
> pomysł, to będziesz go zaciekle bronił :-) Jeśli tak, to bardzo Cię 
> proszę, w oddzielnym wątku.

Jak rozpoczniesz... ;)

> W skrócie moja niechęć do tego rozwiązania bierze się stąd, że kod 
> kliencki w moim przekonaniu nie powinien być zmuszany do operowania 
> większą liczbą obiektów, niż to konieczne. Jeśli _może_ operować Sesją 
> (albo jednym z interfejsów Sesji, jeśli konieczne jest zabronienie 
> klientom dostępu do określonych metod tej klasy), to po co kazać mu 
> operować na IdentyfikatorzeSesji oraz na MenedżerzeSesji (zakładam, że 
> mówimy o kliencie, który tę Sesję skądś już ma - nie musiał jej wyszukać 
> w SessionMenedżerze)?

Powiedzmy, że zażądał utworzenia nowej sesji i dostał jej identyfikator.

Nie rozumiem, o czym ty w ogóle do mnie rozmawiasz - robisz interfejs,
powiedzmy, SessionIf (bo tak w Javie nawet chyba byłoby lepiej), z interfejsu
wyprowadzasz Session, robisz funkcję do tworzenia sesji (najlepiej jako metodę
managera), a ta ma zrobić new Session, ale zwrócić referencję do SessionIf
(mogłem coś pokręcić w składni - nie czuję się mocny w Javie ;):

public class SessionIf { .. }

class Session implements SessionIf { ... }

public class Manager { ...
	SessionIf createSession( ... ) { return new Session( ... ); }
	...
}

Klient:

SessionIf s = manager.createSession( ... );

manager.doSomethingWith( s );

itd.

Jaką ty tu "większą liczbą obiektów" operujesz?

> Drugi powód to moja osobista preferencja - od czasu, gdy zacząłem 
> programować obiektowo, przedkładam wyrażenia typu obiekt.operacja() nad 
> algorytm(struktura_danych), a metoda deactivate(Session) klasy 
> SessionManager przypomina mi to ostatnie wywołanie.

Inaczej mówiąc: przedkładasz ładną i przyjemną dla ciebie składnię nad istotę
designu programu. To bardzo źle ci wróży na przyszłość.

> Nie lubię zredukowanych obiektów typu "opaque identifier", Transfer Objects,
> albo rozpowszechnionych w świecie Javy tzw. "JavaBeans" - JavaBeans
> zredukowanych do roli struktur danych, bez ciekawego zachowania.
> Programować przy pomocy "opaque identifiers" można bez żadnych obiektów.

Ale nie zawsze można programować obiektowo bez żadnych opaque identifiers.

Zresztą - jeśli nie chcesz tak, to masz drugie wyjście, które ci
zaproponowałem: manager typu "Overmind" (tak, określenie jest wzięte ze
Starcrafta :). Nie jest zdefiniowany jako osobna klasa, tylko definicja
managera sesji zawiera się w całości w klasie Session, z użyciem definicji
statycznych.

> >>Przyjmijmy 
> >>jednak, że możliwość deaktywacji sesji z zewnątrz jest udostępniona na 
> >>potrzeby administratora systemu, który lubi od czasu do czasu się 
> >>powtrącać i coś skasować względnie zdeaktywować.
> > 
> > 
> > No to dobra - a teraz kolejne pytanie: co to jest deaktywacja sesji i jakie
> > konsekwencje ma ona dla całego systemu? Innymi słowy - tu już wtrącam znów z
> > teorią stanów cząstkowych - jakie operacje trzeba wykonać w celu deaktywacji
> > sesji, by pozostawić cały system w stanie stabilnym?
> > 
> > Skąd pytanie: załóżmy (bo być może tak jest), że manager zarządza sesjami i
> > manager musi w jakiś sposób odnotować w swoich zasobach, że dana sesja została
> > zdezaktywowana, w związku z czym musi, np., usunąć ją z jakiegoś zbiornika, a
> > może ma jakieś własne dodatkowe dane opisujące sesję i coś w nich trzeba w
> > związku z tym zmienić. W związku z tym, operacja deaktywacji, jaka może być
> > zdefiniowana wyłącznie jako metoda Session, będzie wykonywać deaktywację tylko
> > z poziomu samej siebie, ale nie z poziomu managera. Ponieważ stan w managerze
> > musi być w związku z deaktywacją zsynchronizowany ze stanem sesji, więc
> > wykonanie operacji na samej sesji doprowadza system do niestabilnego stanu (bo
> > sesja zdechła, a manager sobie tego odpowiednio nie odnotował).

> Jest dokładnie tak, jak piszesz. Jednak Twój wniosek, że "deaktywacja 
> sesji z zewnątrz powinna być w jakiś sposób uniemożliwiona i możliwa do 
> wykonania tylko przez managera" uważam za błędny.

No to bardzo dziwne.

Jeśli, jak potwierdziłeś, wykonanie deaktywacji na samej sesji pozostawiłoby
system w stanie niestabilnym, to znaczy, że ta operacja powinna być
udostępniona wyłacznie dla innej procedury, która wykona na sesji deaktywację
jako część całej akcji (po której to części system będzie w stanie
niestabilnym), a następnie dopełni odpowiednich czynności, po których stan
systemu jest stabilny.

> Ta deaktywacja _może_ 
> być zrealizowana tak, jak mówisz, ale _lepszym_ rozwiązaniem jest 
> zdaniem użycie w miarę ogólnego schematu powiadomień (żeby nie użyć 
> słowa "Observer") do zadbania o to, by menedżer miał aktualny stan.

To ty chyba mylisz rolę menedżera i kooperatora. Już ci powiedziałem - w takim
systemie nie ma stosunku nadzorca-wykonawca, jest tylko dwóch kooperatorów:
sesja i ten niby manager.

Jest to najgorsze z możliwych wyjść z bardzo prostej przyczyny: jeśli manager
ma być managerem, jego istnienie ma sens; jeśli manager ma być kooperatorem,
to jego istnienie jest na plaster do dupy potrzebne.

Na razie nie widzę, żebyś przedstawił jakikolwiek sensowny argument za tym, że
tak nie jest, a ciebie po prostu chwilowo najwyraźniej jara koncepcja
Observera i mechanizm sygnałów i slotów i chcesz zastosować to na siłę.

> Dlaczego lepszym?
> Lepszym dlatego, że klient, który posiada referencję do Sesji nie 
> potrzebuje referencji do jej menedżera, żeby ją zdeaktywować.

To mnie nie przekonuje.

> Co więcej, jeśli tę Sesję dostał od innego obiektu, może nawet nie wiedzieć,
> że coś takiego, jak menedżer sesji istnieje!

To mnie tym bardziej nie przekonuje.

Co więcej, tym bardziej mnie to przekonuje, że manager sesji jest tworem
niepotrzebnym (niepotrzebnym jako osobna klasa, bo można jego koncepcję
zrealizować jako Overmind).

> Drugim powodem jest ważna zasada programowania obiektowego - Singular 
> Responsibility Principle.

Co??? Zasada osobliwej odpowiedzialności? Chyba się zaczynasz lekko gubić :)

> Menedżer skupia się na swoim podstawowym 
> zadaniu - wyszukiwaniu sesji

Zaraz - dotychczas rozumiałem, że ma on przechowywać sesje. Ale wyszukiwać? Po
co na co i dlaczego

> (oczywiście można teraz słusznie 
> zakwestionować jego nazwę i to będzie krok w dobrym kierunku),

I w ostateczności dojdziemy do tego, że można nawet zakwestionować jego
istnienie.

> Sesja 
> skupia się na swoich zadaniach. W nieszczęsnych programach, w których 
> zdarzało mi się widzieć dyskutowany antywzorzec, obiekt Menedżera 
> dublował metody Sesji 1:1, nawet wtedy, gdy nie potrzebował aktualizować 
> swojego stanu przy zmianie danej Sesji - bo niby dlaczego miał dublować 
> je wybiórczo? Prowadziło to do absurdalnego wręcz rozrostu kodu różnej 
> maści Menedżerów, które w swojej większej części grały po prostu rolę 
> Man in The Middle.

Zgadza się! Ale pomińmy tak bardzo złe designy - to już omawialiśmy wcześniej.

> Co do wspomnianej "hierarchizacji", to widzę wartość w dzieleniu 
> aplikacji na logiczne "poziomy" i konsekwentnym stosowaniu reguły, żeby 
> kod z jednego poziomu operował na identycznym poziomie abstrakcji (np. 
> żeby operowanie na Sesjach nie mieszało się z obsługą wyjątków typu 
> FileNotFoundException). Jednak stosowanie hierarchii potrafi też 
> wypaczać się w potworki w rodzaju opisanych Menedżerów, na co trzeba 
> zwracać uwagę.

Ale źle to widzisz.

To, co ty chcesz zrobić, to jest wypaczona hierarchia - zamiast trzymać się
poziomów hierarchii i tym samym poziomów kodu (a tym właśnie byłoby sterowanie
sesją tylko z poziomu managera, wedle SessionIf, jak ci zaproponowałem),
usiłujesz uczynić managera i sesję współpracownikami i obiektami będącymi na
równych prawach. To jest właśnie wypaczenie hierarchii. Upierasz się też przy
tym, żeby robić je osobnymi obiektami działającymi na zasadzie współpracy, nie
zauważając, że przy takiej konstrukcji istnienie klasy managera jest rzeczą
najzupełniej zbędną.

> > Zauważ, że hierarchia jest tutaj tak, czy siak, narzucona przez sam fakt, że
> > sesje mają swojego managera. Jeśli to ma być manager, który zarządza sesją, to
> > zarządza również wszelkimi przejawami ich działania: tworzy sesje, zamyka
> > sesje, więc nie widzę powodu, dla którego nie miałby również mieć wyłaczność
> > na zarządzanie obiektami sesji. Obiekt sesji może mieć publiczny interfejs,
> > który pozwalałby jej na różne operacje, ale które sa charakterystyczne dla
> > obiektów "aktywnych", natomiast nie takie, które kończą jej życie.
> > 
> > Hierarchia taka powoduje, że naturalnym podejściem staje się dzielenie
> > operacji na poziomy, przy czym operacje na niższym poziomie wykonują te
> > obiekty stojące niżej w hierarchii, a te na wyższym poziomie - wyżej. Manager
> > zatem ma dostęp do tego, co robi sesja, i jest w stanie sam na tej sesji różne
> > rzeczy wykonać, natomiast operacje samej sesji mają dotyczyć stanu tylko i
> > wyłącznie jej. Inaczej mówiąc, sesja operuje tylko na swoim własnym stanie, a
> > manager operuje na własnym stanie oraz na stanie sesji. Taki model narzuca
> > sama hierarchia.
> > 
> > Dlatego zupełnie naturalną rzeczą jest, że sesja ma swoją metodę od
> > dezaktywacji, która wykonuje określone czynności wyłącznie w ramach sesji,
> > a manager w celu zdezaktywowania określonej sesji, każe sesji się najpierw
> > zamknąć, a następnie usuwa sesję. Manager nie potrzebuje, żeby sesja go o
> > czymkolwiek powiadamiała - sam z założenia rządzi sesjami i każe sesjom tylko
> > wykonać określone czynności.

> Być może popularną i wydającą się naturalną (ze względu na prostotę 
> implementacji dla programisty), ale, co jest od tego ważniejsze - gorszą 
> z punktu widzenia programisty-klienta. A jak wiadomo to "klient nasz 
> pan". Dlaczego gorszą, opisałem wyżej.

Przecież nie każę ci duplikować u managera wszystkich metod sesji. Metody
dostępne publicznie dla klienta możesz zadeklarować w SessionIf. Jedynie
tworzenie i deaktywacja sesji będą wykonywane jawnie przez managera sesji.

Jeśli z kolei - również słusznie - uważasz, że i tak najlepiej, żeby używać
tylko metod sesji, a nie raz z managera, a raz z SessionIf, to do tego celu
potrzebujesz tylko jednej klasy: Session. I realizacji managera jako Overmind.

> > Natomiast to, co ty tutaj próbujesz zrobić, to postawić managera sesji jako
> > kontraktora, czy współpracownika sesji, bo w określonych sytuacjach sesja
> > staje się nadzorcą dla managera. Tak niestety jest, również w technologii
> > sygnałów i slotów, że obiekt nadajnika staje się nadzorcą (nadzorcą
> > specjalizowanym oczywiście, czyli nadzorcą tylko w pewnym, zawężonym obszarze
> > działań) dla obiektu odbiornika (co nie staje w sprzeczności z faktem, że
> > obiekty mogą być takimi relacjami związane w obie strony).

> Niestety?? To raczej dobrze!

Zaraz... dobrze, że sesja staje się managerem dla managera sesji, który jest
jej managerem?

To mi przypomina historyjkę o chłopaku, który ożenił się z wdową, a jego
ojciec ożenił się z jej córką. Jak się temu chłopakowi urodził syn (a ojcu
córka), to nagle się okazało, że jego syn jest jednocześnie jego wujkiem, a
gościu jest własnym dziadkiem (gościu w ten sposób ubiegał się o zwolnienie z
wojska - do przeanalizowania tych "rodzinnych koneksji", które prowadzą do
w.w. rozwiązania, trzeba naprawdę niewąskiej głowy ;).

> Po to odbiorca zdarzeń się rejestruje w 
> nadajniku, żeby ten ostatni go poinformował o pewnych zdarzeniach.

I po co pleciesz takie bananały. Po to skoczyłem do kiosku, żeby kupić fajki.

> Taki układ jest najczytelniejszy:

Nie przedstawiłeś wad i zalet czytelnościowych pozostałych dwóch rozwiązań,
więc nad wyborem "top readable" dopiero będziemy się zastanawiali.

> SessionManager troszczy się o aktualność 
> swojego stanu, więc korzysta z tego, że Sesje rozgłaszają zmiany swoich 
> stanów i przy pierwszej nadarzającej się okazji (najczęściej konstrukcja 
> Sesji) prosi Sesję, żeby jemu też dała znać o swojej deaktywacji.

Rozgłaszanie stanów robi się wtedy, gdy obiekt jest całkowicie publiczny i
rozgłasza stan, jaki mógłby interesować kogokolwiek i mógł potencjalnie zostać
nadany z nieokreślonych (z punktu widzenia klienta) miejsc. W tym przypadku
nie ma miejsca ani jedno, ani drugie.

Co więcej, dezaktywacja sesji powoduje jej faktyczne usunięcie z systemu (w
sensie logicznym). Czyli w efekcie tego wszystkiego, tak naprawdę każdy
klient, który korzysta z sesji, też będzie musiał sobie zainstalować własny
slot i podpiąć się nim pod sesję. To jest już po prostu kuriozalny przerost
formy nad treścią: zamiast, jak normalnie, kazać sesji się zamknąć i wyzerować
jej referencję (co można zaprogramować w jednej metodzie, przy czym zerować i
tak nie musimy, jeśli referencja do sesji była zmienną lokalną), robimy
zamykanie sesji i tu niejawnie zostaje zawołana metoda klienta, żeby wyzerować
mu referencję do sesji. Czy zrobić jakikolwiek inny whatever.

Czemu przerost formy nad treścią? Otóż, system powiadamianie jest tutaj
całkowicie zbędny, bo po pierwsze - każdy głupi wie, że po dezaktywacji sesji
sesja zostanie zdezaktywowana (więc nie ma tu żadnej zmiany stanu o nieznanych
przyczynach, do czego stosuje się właśnie Observera), a po drugie, i tak
wiadomo, gdzie trzeba wykonać czynności związane z dezaktywacją sesji, bo
właśnie tą dezaktywację przeprowadzamy. W związku z tym, system powiadomień
daje ci to, że klient musi a) dodać sobie metodę, którą wywoła przy
dezaktywacji sesji i b) zarejestrować się jako Observer u sesji zaraz po jej
utworzeniu. Oczywiście żadnej korzyści klientowi to nie daje.

> Tak 
> więc mimo, że aktualizacja stanu SessionManagera odbywa się poprzez 
> Sesję, to dzieje się tak na wyraźne żądanie SessionManagera, zatem to on 
> kontroluje sytuację, a nie na odwrót.

No dobrze, załóżmy że tworzenie to jeszcze kontroluje.

> Sesja sama nie przypisze sobie 
> żadnego SessionManagera (poza tym żeby to zrobić, to musiałaby mieć do 
> niego jakąś referencję - a ja nie zakładam nawet tego, że ona wie 
> _cokolwiek_ na temat istnienia SessionManagerów).

Pięknie! Ale skoro się przy tym upierasz, to nie możesz dopuszczać do tego, by
dezaktywował ją ktoś bezpośrednio. Powinieneś zlecać dezaktywację managerowi.

> Manager, jeśli miałby nawet potrzebę _zablokowania_ niektórych zmian w 
> Sesji, mógłby się zarejestrować na odbiór pewnego zdarzenia, ogłaszanego 
> _przed_ wykonaniem pewnej akcji (patrz constrained properties w 
> specyfikacji JavaBeans).

Taa jasne - i pewnie rzucić wyjątkiem!

Coś się tak uparł na utrudnianie sobie życia (i klientowi, przypominam!).
Przecież to takie proste do zrobienia, a ty musisz kombinować aby tylko było
jak najbardziej naobkółko.

> > A jak będziesz tworzył nową sesję, to jak to zrobisz? Będziesz wołał
> > konstruktor Session podając jej managera, jako argument? A Sesja wywoła
> > manager.addSession( this )?

> Zapewne tworzenie Sesji będzie odbywać się w SessionManagerze.

No właśnie. A skoro manager zajmuje się jej tworzeniem, to powinien też
zajmować się jej dezaktywacją. Te dwie rzeczy to jest jeden określony
"poziom".

> Zatem tuż 
> po jej stworzeniu SessionManager zarejestruje się w tej Sesji jako 
> obiekt zainteresowany jej zmianami 
> newSession.addStateChangeObserver(this). Sesja nie będzie nic wywoływać 
> na swoich obserwatorach dopóki nie zmieni się jej stan. Natomiast 
> SessionManager, świadomy początkowego stanu Sesji, w chwili tworzenia 
> jej instancji zaktualizuje swój stan addSession(newSession).

Przy czym jedyny stan związany z sesją istniejący poza sesją to jej pozycja w
liście sesji u managera, a jedyny stan sesji, o którym sesja może powiadamiać,
jest jej żywotność. Przy czym zmiana stanu żywotnści sesji na zdechły
powoduje, że sesja jest już do wyrzucenia.

Gościu zrozum wreszcie jedną rzecz: Observer jest przeznaczony do tego, żeby
obserwować zmieniające się stany, których zmiana może być wynikiem różnych
akcji, o których mało kto wie, poza tym, kto je wykonywał, a często nawet i to
nie (bo akcja z zewnątrz woła metodę i nic nie wie o tym, jakie zmiany stanów
cząstkowych obiektu to spowoduje). Natomiast tutaj zarówno akcję zmieniającą
stan, jak i konieczną akcję zsynchronizowaną ze zmianą tego stanu masz
dosłownie jak na dłoni. To ma mniej więcej tyle samo sensu, co dzwonienie z
telefonu do gościa, który siedzi po drugiej stronie pokoju dokładnie za twoimi
plecami.

Nie przekonałeś mnie jak dotąd, że wiesz, co robisz, wręcz przeciwnie:
utwierdzasz mnie coraz bardziej w przekonaniu, że Observer to dla ciebie
fajowy bajer, jara cię to, i chcesz za wszelką cenę zastosować to rozwiązanie,
choćby nawet był to najgłupszy możliwy pomysł dla danego przypadku.

Rozumiem cię. Sam to kiedyś przechodziłem. Też narobiłem więcej kodu i
organizacji i definicji, żeby było fajnie, ładnie i zorganizowane. Czułem
się wyśmienicie, że posiadam wiedzę, jak konstruować złożone systemy. Jak
napisałem i zobaczyłem, ile to powoduje kłopotu, przeszło mi. Kilka takich
myków przekonało mnie, jak wybierać sensowne rozwiązania. Ta droga jest
najwyraźniej przed tobą. Ja wiem, że i tak mnie nie posłuchasz i zrobisz jak
zechcesz, a moje słowa na nic się zdadzą. Ale właśnie dlatego moim obowiązkiem
jest stać na straży zdrowego rozsądku i nie dać się przkonać. ;)

> > Takie postawienie sprawy jest o tyle bez sensu, że manager w takim wypadku
> > właściwie do niczego nie służy, poza tym, że zawiera listę sesji. 

> Lista sesji to bardzo ograniczone ujęcie i było świadomym uproszczeniem 
> na użytek przykładu - poza nią manager może zawierać listę sesji 
> aktywnych, listę sesji rozpoczętych w ostatniej godzinie, tak jak baza 
> danych zawiera indeksy dla danej tabeli w celu szybszego wyszukiwania 
> rekordów. Tak więc - zawiera listę sesji, ale prywatną i udostępnia 
> szereg metod służących do wyszukiwania sesji.

Nie widzę jak na razie żadnego powodu, żeby manager musiał być osobnym,
zewnętrznym obiektem.

> Mam nadzieję, że teraz już widać, że taki manager do czegoś służy?

Widać - do niczego.

> Co do jego nazwy, to już wspominałem, że mogłaby być lepsza - obecną 
> stosuję wyłącznie z powodów historycznych - taką widziałem w kilku 
> projektach.

Nie wiem, jak nazwać klasę obiektu, który do niczego nie służy. Te wszystkie
dane, o których mówisz, mógłby zawierać równie dobrze obiekt managera będący
obiektem statycznym klasy Session. Wtedy każda sesja obracałaby nim sobie, jak
by chciała.

Ja rozumiem, że chcesz folgować idei rozdzielania obiektów, które są osobne w
stosunku do siebie, ale akurat rozdzielanie wyraźne Session i SessionManagera
nie ma za wiele sensu, skoro funkcjonalność SessionManagera jest wpisana w
działanie Session (e.g. nie przewidujesz innego używania klasy Session, niż we
współpracy z SessionManager - skoro tak, to po cholere musisz ukrywać
SessionManagera przed Session?).

Chyba że manager ma posiadać jeszcze jakieś funkcjonalności związane z jego
interfejsem, ale o niczym takim nie wspomniałeś.

> > Taki projekt
> > jest całkowicie na bakier z hierarchizacją, która stanowi ważną część
> > programowania obiektowego. 

> Programowania to być może tak, bo raczej nie obiektowego w 
> szczególności.

Hierarchizacja jest częścią programowania obiektowego, czy ci się to podoba,
czy nie.

> Na bakier może być poza tym jedynie z hierarchizacją w 
> pewnym szczególnym, wąskim rozumieniu, bo jak wykazałem wyżej, kontrola 
> pozostaje w gestii managera, jedynie w mniej bezpośredni sposób.

No to się zdecyduj - albo masz hierarchię i manager kontroluje sesje, albo
masz kolaborację, ale wtedy nie oszukuj się, że manager czymkolwiek zarządza.
Powiedziałbym nawet: SessionManager jedynie hoduje gada na własnej piersi. :)

> Dla mnie zresztą mógłby być na bakier z hierarchizacją, tak jak z 
> wieloma innymi *-zacjami, jeśli tylko ostateczna jakość API 
> _z_punktu_widzenia_klienta_ będzie przez to lepsza.

Dla klienta najlepsze API będzie takie, jeśli:

1. Będzie można łatwo utworzyć sesję, zdobyć jej identyfikator, a także używać
go do operacji na sesji. W szczególności, że sesję będzie się tworzyć jednym,
prostym wywołaniem.

2. Będzie funkcjonalność do zamknięcia sesji (i tym samym zwolnienia jej
zasobów). Z identyfikatorem można wtedy już zrobić co się podoba.

Co się dzieje wewnątrz, już nikogo nie interesuje.

Jeśli zrobisz to na zasadzie interfejsu klienta do sesji, wtedy tworzenie i
dezaktywacja sesji będzie w gestii managera.

Jeśli zrobisz to na zasadzie managera w formie Overmind, to tworzenie sesji
będzie to po prostu new Session, a dezaktywacja sesji będzie wywoływana przez
metodę sesji.

Oba rozwiązania mają takie samo znaczenie dla klienta. I oba są spójne.

> Zastosowanie się w 
> tym przypadku do zasad tak pojmowanej "hierarchizacji" bardzo dobrze 
> pasuje do słów Adama o tryumfie technikaliów nad rzeczywistością, bo 
> bardziej liczą się jakieś tam szczegóły wewnętrznej architektury, niż 
> faktyczna użyteczność dla klientów.

No i powiedz teraz, jakąż to "użyteczność dla klientów" chcesz tutaj klientowi
zaproponować - zwłaszcza, że klient o tym obserwerowaniu i tak nic nie będzie
wiedział.

> > Zależności zarówno stanów, jak i zachowania są
> > tutaj poplątane, odmiennie niż w strukturze hierarchicznej. 

> A tak - te zależności są odmienne i to bardzo, ale jeśli połapanie się w 
> nich stanowi dla Ciebie problem, to już raczej wyłącznie Twoja sprawa.

To nie jest kwestia "połapywania się", tylko kwestia pokrętnego designu. Nie
bądź taki szybki w twierdzeniu, "w czym to ty się nie połapiesz", bo kiedyś
naprawdę się nie połapiesz i będzie ci głupio ;)

> > Jest to najgorszy
> > możliwy sposób wykorzystywania wiedzy książkowej, bo nie dość, że łamie to
> > wszelkie ugruntowane standardy programowania obiektowego, 

> jak "hierarchizacja"? :-)

Na przykład. Ale nie tylko, również kwestię kierunkowości przesyłania
komunikatów i tworzenia jasnych powiązań między obiektami.

Ja rozumiem, że Observer jest fajny i jara cię, mnie też koncepcja mechanizmu
sygnałów i slotów się bardzo podoba, ale do jasnej cholery - to nie jest
silver bullet, tylko mechanizm do stosowania w określonych sytuacjach. A
spróbuj wyobrazić sobie taką:

Mamy klasy A i B i ich obiekty a i b.

Obiekt 'a' rejestruje się w obiekcie 'b' na sygnał X podłączając swój slot Y.
Procedura zdefiniowana jako slot Y bierze obiekt b i wywołuje mu pewną metodę,
która zmienia jego stan. Zmiana tego stanu generuje sygnał X.

I mamy pięky "stack overflow".

Takie są niestety uroki callbacków. Wywołania bezpośrednie, w jednym kierunku,
zgodnym z hierarchią obiektów, są tego problemu w oczywisty sposób
pozbawione.

> Pokaż mi, co to za ugruntowany standard 
> programowania obiektowego i jakie inne "wszelkie" równie mocno 
> ugruntowane standardy mój sposób łamie

Nie rozumiem.

> > to jeszcze stanowi
> > swoisty przerost formy nad treścią. Dlaczego?

> o proszę :-)

> > Dlatego, że jeśli przyjmiemy już coś takiego, że manager nie rządzi sesjami,
> > tylko sesje go powiadajamiają o określonych działaniach, to PO JAKI CHUJ JEST
> > NAM TEN MANAGER? 

> Koledze nerwy już puszczają od takich herezji :-)
> Ale gwoli sprawiedliwości dodam, że część zbulwersowania ma prawo 
> wynikać z nazwy "manager", która jest - do omawianego zakresu 
> odpowiedzialności - nieadekwatna.

Jeśli to coś ma rządzić sesjami, to nazwa manager jest na miejscu, oczywiście.
A że to ma rządzić sesjami, to sugerujesz już od jakiegoś czasu. Ale poza
sugestią, jakoś niczym konkretnym tego nie popierasz, a twoje propozycje zdają
się temu wręcz przeczyć.

> > Zrób po prostu listę sesji jako pole statyczne klasy Session!

> A to Ci dopiero pomysł, nie ma co! Wprowadzajmy więcej statycznych 
> elementów, co tam - garść singletonów tu i ówdzie, jeszcze jakaś 
> statyczna lista i nasze programy będą tak się nadawać do wykorzystania 
> jako samodzielne komponenty (vide mój inny post), jak mało kiedy.

Przepraszam, ale o tym ty teraz właściwie mówisz?

> Wybacz, ale konstrukcje typu static już przerabiałem, a z niektórymi z 
> nich przyszło mi żyć do tej pory. I wierz mi, nie jest to nic, z czego 
> bym się nadzwyczaj cieszył każdego dnia.

Jakoś ci nie wierzę.

Biorąc pod uwagę, że sam nie wyobrażasz sobie używania Sesji bez
SessionManagera, nie wiem, po co i do czego ci potrzebna taka modularność. Nie
mówiąc już o tym, że sens przenoszenia samej klasy Session...

zresztą już mi brakuje słów. Widać nie przekonałeś się jeszcze, ile warte w
praktyce jest generycyzowanie wszystkiego na każdą możliwą okoliczność.
Najwyraźniej wszystko jeszcze przed tobą.

Ja rozumiem, że pewnie OCP jest dla ciebie ważne, ale tak naprawdę nie ma to
większego znaczenia poza bibliotekami, gdzie kod musi być zafixowany i o
wszelkim maintenance można zapomnieć. W przypadku, gdy mamy kod możliwy do
wszelkich możliwych maintenance - można zapomnieć o zakazie modyfikacji klasy.
Będzie trzeba, to się ją i tak zmodyfikuje. To, o co naprawdę należy zadbać,
to o to, żeby kod był ładnie podzielony na części (również składowe), żeby
robienie nowych rzeczy było w miare możliwości możliwe do oparcia na jak
największej liczbie istniejących rozwiązań.

Ale do tego celu potrzebujesz generycznych klas i to nie takich, które są
generyczne przez swoją definicję, ale są generyczne przez logikę i design
kodu. Jaki poziom generyzmu jesteś w stanie sobie wyobrazić dla takiej klasy
Session, że chcesz ją na siłę uniezależniać od SessionManagera? Albo inaczej:
czy niezależność od SessionManagera jest tym elementem generyzmu klasy
Session, o który ci chodzi, gdy dbasz o jej generyczność?

> > Odpada ci pisanie dodatkowej klasy SessionManager, odpada ci też robienie
> > jakichś wymyślnych interfejsów Observera. 

> Wymyślnych?? Człowieku, nad jakim oprogramowaniem Ty pracujesz

Pracuję nad oprogramowaniem, z którego korzystasz niemal każdego dnia i nie
zdajesz sobie z tego sprawy. Pracuję nad oprogramowaniem do systemów
obsługujących stacje przekaźnikowe (BTS) do sieci telefonii komórkowej.
Pocieszę cię tylko z jedną rzeczą: żadna z sieci komórkowych w Polsce nie jest
klientem mojej bieżącecj firmy.

> - u mnie Observer to chleb powszedni!

Aaaa... no to wszystko wyjaśnia. Widocznie wy już tak macie, że bez Observera
nie potraficie żyć.

U mnie, niestety, Javy się nie stosuje. Przynajmniej w mojej bieżącej pracy,
bo w tej nowej, którą zaczynam od września, stosuje się jak najbardziej, ale
nie wiem jeszcze, jak tam mają napisany kod, dopiero się tego dowiem.

> > Masz zatem dwie możliwości: albo robisz to na zasadzie, że sesja podlega
> > managerowi i manager wyłącznie wykonuje wszelkie operacje, które zmieniają
> > "liczebność sesji", 

> No to u mnie tak podlega, przez wzorzec Observer

Powtarzam: wykonuje. Manager wykonuje. Również dezaktywację sesji.

> > albo manager jest ci całkowicie zbędny. 

> Taak... I dokładam jeszcze kilka singletonów, bo kocham konstrukcję 
> static ;-)

Nie mówiłem o żadnych singletonach, to już twoja chora wyobraźnia. A skoro
obiekty w polach statycznych wiążesz z singletonami, to coś mi się wydaje, że
sam się musisz jeszcze trochę pouczyć Javy.

> Nie rozważaliśmy do tej pory jeszcze jednego aspektu - wiele 
> obserwatorów jednej Sesji.

Ha! No oczywiście, jak mogłem zapomnieć. Jeden z managerów utworzył sesję, a
który - zgadnij!

> Jest dla mnie normalnym scenariuszem, że 
> zmianami w sesji zainteresowanych jest w jednym momencie kilku 
> obserwatorów naraz - każdy z nich interesujący się odrębnym aspektem tej 
> samej Sesji.

Tego nie neguję! Ale rozmawiamy o zupełnie innych aspektach. Jeśli Observer
obserwuje jakieś istotne stany sesji - ok. Ale kwestia jej aktywacji i
dezaktywacji to jest zupełnie inny poziom programowania.

> Rozwiązanie hierarchiczne wypada znacznie gorzej od wzorca 
> Observer wg fundamentalnej zasady Open-Closed.

Akurat OCP nie ma tutaj absolutnie nic do rzeczy.

> W wypadku Observera 
> zgodność z tą zasadą otrzymujemy na starcie, w rozwiązaniu 
> "hierarchicznym" musimy kombinować.

Musisz się po prostu zdecydować, czy manager ma być managerem, czy też
usługodawcą pracującym na rzecz sesji. Jeśli to drugie, to cała konstrukcja
będzie wyglądała zupełnie inaczej.

> Reasumując, nic a nic nie przekonałeś mnie do rozwiązania 
> "zhierarchizowanego" (którego nie przypisuję wcale Tobie, bo jest 
> rozplenione jak chwast po większości oprogramowania obiektowego jakie 
> znam - stąd mój post na tą grupę). Chętnie jednak dowiem się, jak 
> jeszcze uzasadnisz wyższość bronionego przez Ciebie rozwiązania, bo jak 
> na razie nie dowiedziałem się o niczym, o czym nie wiedziałbym wcześniej.

Wyjaśnienia masz wcześniej. Również wyjaśnienia, dlaczego bronię swojego
zdania.

Jest bardzo prawdopodobne, że po prostu zbyt słabo i ogólnikowo przedstawiłeś
swoją koncepcję, dlatego mi się to nie zgadza. 

> PS. Moje uznanie dla ogromu pracy włożonego w 
> http://www.intercon.pl/~sektor/cbx/

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ 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:

> Ciekawe, że Java jest gloryfikowana jako język, który - w odróżnieniu od C++ -
> uniemożliwia ludziom robienie głupot, podczas gdy C++ jedynie je utrudnia, a
> czasem i to nie. W tym wypadku okazuje się dokładnie odwrotnie: w C++ możesz
> stworzyć klasę, której obiekt będzie miała prawo utworzyć tylko inna klasa
> (lub funkcja, lub wybrana metoda wybranej klasy), a w Javie możesz tylko
> wrzucić klasę w pakiet i liczyć na to, że użytkownik nie zdefiniuje sobie w
> tym samym pakiecie klasy. Ale oczywiście w tym wypadku i tak Java jest lepsza.
> ;-P

Kod Javy uruchamiany w środowisku z wyłączonym security, to i do 
prywatnych składowych klas bez problemu może się dostać.

Oczywiście jakieś tam konwencje, gwarancje autorów, czy zakazy robienia 
głupot można sobie między bajki włożyć.

A jak postąpić możesz z rozważanym tu "problemem" podano np. tu:
http://java.sun.com/security/seccodeguide.html#gcg15


piotr