🚀 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"