Java Reference
In-Depth Information
Pattern Use
Factory Method (see page 21): In JavaBeans, the Factory Method is used to instantiate beans through the
Beans.instantiate method and to abstract the real creation of the object. The caller of the method sees no
difference between whether the bean has been restored from serialization or that a new object has been
created—making it easier to reuse beans. A customizer only has to change some properties to let the bean appear
as a different type, serialize the bean, and give it a name with the . ser extension.
Singleton (see page 34): Applications use the Introspector to find information about a Bean. The
Introspector provides information about what methods, events, and properties a bean instance supports. It
traverses the inheritance tree and looks for implicit and explicit information to use in building a BeanInfo object.
Only one Introspector is needed to provide this functionality. To prevent redundancy, only a single instance is
used so it can cache information for other requests.
Adapter (see page 142): The Adapter is specifically mentioned in the JavaBeans Specification ([JBS] although
there it is called Adaptor). The task of the Adapter is to decouple the event source from the actual listeners and
perform one or more of the following tasks:
Implement a queue for the incoming events so that events may be searched in the situation where a specific event
in a series of events is missed.
Provide a filter to prevent all events from arriving at the actual target, letting only those events pass that fulfill
certain criteria. You could set up an Adapter between a temperature bean and a warning bean and only forward
the change events if the temperature changes more that 0.1 degrees Celsius instead of just every minuscule
change.
Demultiplexing. A class can implement a specific method from an interface only once. If the same object is going
to listen to multiple sources of the same event, but the reaction should be different based on the source, the
implementation of the listener method has to change for every new source and the method will become bloated
with large switch statements. Here the Adapter pattern is used to demultiplex. That means an Adapter instance
is created for every event source and that instance is registered with the source. When the listener method gets
called, the Adapter invokes another method on the actual listener, a different method for each different source.
Now the actual listener no longer needs to determine where the event came from. That is the responsibility of the
adapter.
Connect a source and a listener. This is useful when the event source and actual listener are of different event types. Its functionality is
essentially that of the “true” Adapter , as described in the Adapter pattern.
Observer (see page 94): JavaBeans provides support for bound and constrained properties in beans.
Bound properties mean that beans can be connected together, and when a bound property changes, all interested
beans are notified. These properties are called bound because they allow other classes and objects to bind
behavior to the changes of the property.
The bound property acts as the Observable and the beans interested in the changes are the Observers to that
property. They are registered through the method addPropertyChangeListener( PropertyChangeListener
listener) and must implement the PropertyChangeListener interface .
When the property change occurs a PropertyChangeEvent is created with, among others, the old and new values
and the propertyChange method is called on the listeners passing the PropertyChangeEvent as the argument.
Constrained properties are a variation on this principle, the difference is that the listeners may throw a
PropertyVetoException if the listener objects to the change from the old to the new value. The listeners are
registered through the method addVetoableChangeListener( VetoableChangeListener listener) and they
must implement the VetoableChangeListener interface. The bean where the property change occurs calls the
vetoableChange method on the registered listeners passing a PropertyChangeEvent as the argument. If a
PropertyVetoException occurs, the same bean will undo the change and call the same listeners but with a
PropertyChangeEvent that has reversed the new and old values, effectively rolling back the previous change.
Search WWH ::




Custom Search