Observer pattern, kilka niezrozumiałych elementów.

Witam.

Potrzebuję, żeby mi ktoś wyjaśnił kilka kwestii w observer pattern. Wzorców uczę się z tej strony : http://www.tutorialspoint.com/design_pattern/observer_pattern.htm.

W linku, który podałem jest diagram klas. Nie wiem czy dobrze rozumiem, ale obiekt "Subject" jest obiektem obserwowanym i to on powinien posiadać wszelką odpowiedzialność za rejestrowanie i wyrejestrowywanie klientów? Widziałem wersję, że tym zajmowała się inna klasa.

Ciekawi mnie sprawa klientów, które rozszerzają klasę observer. Dziedziczenie chyba nie jest tu dobrym pomysłem bo w przypadku, gdy klient zostanie wyrejestrowany to dziedziczenie klasy observer pozostanie nadal... Da się to załatwić bez kłopotliwego rozszerzania?

Możesz tam mieć interfejs zamiast tego, ale niewiele więcej. Bo obiekt obserwowany musi jakoś "notyfikować" obserwatorów o tym, że coś się podziało. Więc siłą rzeczy trudno żeby ci obserwatorzy to były zwykłe POJO. Jak byś sobie wyobrażał to informowanie skoro w swoim obiekcie nie masz żadnej metody na to zarezerwowanej?
Alternatywą może być wykorzystanie systemu kolejkowego/messagingu (i JMS) ale tak czy siak klasa która chce wykonywać akcje w odpowiedzi na wiadomości w kolejce musi mieć metodę która to robi...

Co do wykorzystania klasy Observer i dziedziczenia to jest ten zły element w Javie. Odpowiednim podejście będzie w tym przypadku użycie np. Guava Event Bus, czyli szyny zdarzeń. Działa ona w ten sposób, że obserwatorzy rejestrują się w niej podając jakiego typu (klasy) zdarzenia chcą obserwować. Obserwowane obiekty wysyłają do szyny odpowiednie wiadomości, a szyna dystrybuuje je do obserwatorów.

@Koziołek pozwolę sobie zaczepić o mój temat. Wcześniej mój obserwujący jeżeli chciał obserwować moją implementację txt dao implementował interfejs:

public interface TxtDaoEvents {
    void incorrectLine(String line);
    void loadError();
    void writeError();
}

korzystając z Guava Event Bus podzielić to na 3 osobne zdarzenia-wiadomości (klasy np. IncorrectLine, LoadError itd..) czy na jedną np. TxtDaoEvents zbiorczą? Skłaniam się ku 1 rozwiązaniu, ale nie wiem czy nie jest to przerost formy nad treścią.

Jedno zdarzenie jedna klasa. Tak będzie łatwiej to ogarnąć. W dodatku polecam separację interfejsów do obsługi poszczególnych zdarzeń i adnotowanie na poziomie interfejsu tak jak tutaj > https://github.com/Koziolek/ragecomicsmaker/blob/master/src/main/java/pl/koziolekweb/ragecomicsmaker/event/DirSelectedEventListener.java

Jak masz możliwość użycia Javy 8 to warto pobawić się w domyślną implementację metod do obsługi zdarzeń. Szczególnie jak wiesz, że będą one później wykorzystywane w GUI :)