I'm trying to verify my concept about it through the diagram it provided. My current understanding from this pattern is that the subject shouldn't assume much about its observers' actual types and this is done by an abstract interface Observer, and my question is that whether each subject has its own Observer interface.
Comment by Niing
Subject and the abstract
Observer have no knowledge of the concrete details. They only know enough to let the
Subject control when updates happen. Not how.
ConcreteObservers may be many different types but they all must know enough about the
ConcreteSubject to request and use
ConcreteSubjects can be different types as well provided requesting and using their
subjectState is identical. A different interface could be created to ensure this if needed but that's not usually part of whats called the observer pattern.
I think I still can't understand about how one observer subscribe for multiple subjects, but I appreciate your current answer
Comment by Niing
observer subscribing to multiple
subjects isn't the usual pattern but it's possible, in two different ways:
First we should be clear if we're talking about classes or objects. What you've been looking at above is a class diagram. One class can be used to create multiple objects configured in different ways. That can cause confusion with this question so let me address both.
In the case where there are many different classes talking to many other and different classes all of the above still works provided you allow for polymorphism in some way. Whatever defines the
getState() method signature, and so the
subjectState returned, needs to hide the differences in the different
ConcreteSubjects from the
In other words
ConcreteObserver doesn't need to know what it's talking to. Just how to talk to it. So long as it doesn't know what exactly it's talking to, it can talk to anything that speaks it's language. Polymorphism in a nutshell.
In the case where they are simply different objects but always of the same types (classes or interfaces) the polymorphism requirement can be lessened since the only difference between the objects is their state and reference address.
However, if your issue is actually that you want one
observer object to be able to track multiple
subject objects at the same time there is a minor tweak that helps. In this situation it's easy to get confused and ask for
getState() from the wrong
subject. A nifty trick is to have your
subject send a
self (depending on language) reference back with the
update(). This way you know exactly which
subject to call
When there's only one
subject this is sometimes left out of the pattern because they can reuse the reference that was used to subscribe. Why not do it every time? YAGNI.
And as Caleth points out you don't have to use a getter at all. You can have the
subjectState as a parameter of
On the issue of using getter vs parameter you wont find many observer pattern text authors commenting. You will find plenty of tell, don't ask authors commenting.
If you want to go down that road I highly advise you be sure you know the difference between an event and a command because you're creating an event and should treat it as such.