🚀 go-pugleaf

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