See Observer Pattern in the Gang Of Four book, Design Patterns.
In developing a user interface framework patterned on MVC, the most obvious approach is to use the Observer interface and Observable class, or some approximation of these classes to provide synchronization between models and views.
I would suggest instead that the developer study the Java Beans framework, in particular the Design Signatures having to do with Bound Properties, Vetoable Properties, and Events.
These Design Signatures are basically protocol for classes which are Java Beans and specify how classes should define public properties which have a notion of being "bindable" in that "observers" or "interested parties" can bind themselves to the class and be notified when the property changes. In addition, such changes that follow the signature for Vetoable Properties have the feature that the changes can be "vetoed" by the "observers".
By adhering to these Design Signatures (protocol, essentially) the developer will find that in addition to the advantages of utilizing an existing framework he will benefit from the opportunities opened up by having classes which can be trivially packaged as Java Beans, a useful platform independent Component architecture.
Having studied this a little more closely, I'm pretty much convinced that there's not a lot of difference between the general Observer pattern as implemented in Observer Observable and the same pattern as implemented by the JDK 1.1 Events model (which Java Beans use).
The major difference seems to be that using the JDK 1.1 Events model involves creating a new Event Object class for each new event that you will be generating in your component (or bean). This gives you more information than simply sending along a general parameter the way you do with the update(observable, argument) method but it seems that it still works the same way.
If anything, I'm a bit annoyed that they made you implement an interface for each Event type -- the problem with that is if you're a listener on several objects with the same event you have to check to see WHICH one sent you the message. It's not as flexible as the Self Addressed Stamped Envelope pattern used in all three of the major Smalltalk dialects. The sad thing is that the JDK 1.1 HAS reflection -- they could have implemented Self Addressed Stamped Envelope and not had to mess with all this.
Good point. Take a look at Inner Classes As Event Handlers to see how I deal with this in Java using anonymous inner classes.
There are a few problems with the Observer Observable class/interface pair which makes using them rather problematic. For me, the biggest is that Observable is a class rather than an interface, which means that you have to use their implementation, or Observable is worthless. Coupled with the Single Inheritance restriction, that rules it out for many situations. While the given implementation is not terrible in general, I have times when I need to decouple the pair into separate threads to avoid blocking a remote process which is calling back to a client hidden in a browser.
Russel, instead of using Observer Observable, use bound bean properties. Check out the java.beans.Property Change Support. It's the delegate to use with the interface-based bean notification.
That is exactly what I do. I was explaining 'why' I do that instead of using Observer Observable. -- Russell Gold
See original on c2.com 