🚀 go-pugleaf

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?

Przemek Pokrywka