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ć?