Czy Observer Pattern jest zły?

Czytam książkę gdzie jestem na rozdziale który ma stworzyć funkcjonalność komunikowania zmian stanu obiektów do różnych systemów:

Handling messages
Entity events, while useful for a lot of situations, aren't perfect foreverything. For
instance, carrying data between systems is impossible using the event queue. The
events are also being delivered to every single system, which can be wasteful.
Instead, why not have an additional method of communication that not only carries
data around, but also allows systems to pick and choose what they want to receive?
Entity component system messaging serves exactly that purpose, and there just so
happens to be yet another programming pattern, which allows easy implementation
of the message-subscription approach.
The observer pattern
As thename entails, the observerpattern allows its users to pick and choose
what they will be notified of. In other words, the observer will lay dormant after
subscribing to information types it wishes to receive, and will only be notified if
those types are encountered. Let's take a look at a very basic implementation of
the Observerbase class:

Robiąc też research na internecie pierwsze co zobaczyłem to:

Why is Observer Pattern bad?
Observer Pattern is intuitively wrong: The Object to be observed knows who is observing (Subject<>--Observer). ... Only Observers know what they can observe. When this kind of of things happen then software use to be a mess -because constructed against our way of thinking-

Przychodzę z zapytaniem, co o tym myślicie, co proponujecie w zamian albo czy jednak to stosować?

Jak z każdym wzorcem -> wszystko jest dla ludzi. Są sytuacje kiedy takie rozwiązanie ma sens i jest pożądane, a są takie sytuacje kiedy to zły pomysł. W szczególności np. kiedy chcemy wiedzieć czy i kto nas obserwuje. Jeśli nas to nie obchodzi, to wygodniej może być użyc jakiegoś event busa.

W tej książce, którą czytasz, to nie wyjaśniają, że wzorce są charakteryzowane przez problem, kontekst, ograniczenia, rozwiązanie konkretnego problemu, racjonalne uzasadnienie i parę innych elementów? Tak jakby pytać, "Czy młotek jest zły"? Jedno z narzędzi, ale niekoniecznie stosowane do każdego problemu.

Jeśli chodzi o samą funkcjonalność "komunikowania zmian stanu obiektów do różnych systemów:", to prędzej wzorce integracyjne. Obserwator implementowany jest raczej w ramach tego samego procesu/maszyny wirtualnej. Systemy nie muszą być uruchomione na tej samej maszynie, więc potrzebne jest jakieś medium pośredniczące. np. wspomniana przez @Shalom szyna (event bus).

When this kind of of things happen then software use to be a mess -because constructed against our way of thinking-

@cplusplus94: Poprawcie mnie jeśli się mylę, ale całe założenie Inversion of Control nie jest intuicyjne i wbrew myśleniu w przeciwieństwie do spaghetti code, a jednak SOLID się na nim opiera jak i wszystkie firmy używające Springa.

@Bonanzaa czemu nie nieintuicyjne wg ciebie? IoC mówi tylko tyle że ktoś nam daje zależności i tyle. Uważam ze to jest równie naturalne i wygodniejsze z punktu widzenia developera, bo deklarujesz potrzebne mi XYZ i dalej piszesz kod w oparciu o założenie ze ktoś ci to dostarczy, a nie zastanawiasz się skąd wziąć XYZ.

@Shalom: Idąc tym samym tokiem rozumowania dlaczego Observer jest nieintuicyjny, bo dla mnie są bardzo podobne, listener potrzebuje kogoś poinformować i musi wiedzieć kogo. BTW rozumiem że z nazwy patternu wynika, że observer jest podmiotem i decoupling itp.

No nie do końca, bo jednak logika, nawet jęzukowa, sugeruje że to ktos kogoś obserwuje, a nie że obserwowana osoba informuje zainteresowanych ze coś robi :) Przyzwyczajeni jesteśmy raczej że osoba obserwująca jest "aktywną stroną" a osoba obserwowana nawet nie wie przez kogo jest obserwowana.

@Shalom: Tak, tylko zmieniając nazwę na listener dostaniesz ten sam schemat systemu, który już będzie zgodny ze sposobem myślenia. Czy powinniśmy odrzucać ten schemat tylko dlatego że jest źle nazwany(bo najwyraźniej observer nigdy nie będzie potrafił sam wykonać czynności obserwowania)? Ja zawszę myślę o nim z perspektywy listenera, stąd porównanie do IoC.