🚀 go-pugleaf

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.