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
The abstract 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 subjectState. 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
One 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 ConcreteObserver.
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 this or self (depending on language) reference back with the update(). This way you know exactly which subject to call getState() on.
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 subject send subjectState as a parameter of Update.
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.
