Beans Not Observer Observable

See ObserverPattern in the GangOfFour book, DesignPatterns.

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 JavaBeans framework, in particular the DesignSignatures having to do with Bound Properties, Vetoable Properties, and Events.

These DesignSignatures are basically protocol for classes which are JavaBeans 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 DesignSignatures (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 JavaBeans, a useful platform independent Component architecture.

BillKayser

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 ObserverObservable and the same pattern as implemented by the JDK 1.1 Events model (which JavaBeans use).

The major difference seems to be that using the JDK 1.1 Events model involves creating a new EventObject? 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 SelfAddressedStampedEnvelope 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 SelfAddressedStampedEnvelope and not had to mess with all this.

KyleBrown

Good point. Take a look at InnerClassesAsEventHandlers to see how I deal with this in Java using anonymous inner classes.

There are a few problems with the ObserverObservable 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 SingleInheritance 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.

RussellGold

Russel, instead of using ObserverObservable, use bound bean properties. Check out the java.beans.PropertyChangeSupport?. It's the delegate to use with the interface-based bean notification.

RobbShecter

That is exactly what I do. I was explaining 'why' I do that instead of using ObserverObservable. -- RussellGold