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.
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.
That is exactly what I do. I was explaining 'why' I do that instead of using ObserverObservable. -- RussellGold
This page mirrored in JavaIdioms as of April 29, 2006