Introduction
This guideline focuses on designing JavaBeans and different choices a designer can make.
For more information on JavaBeans, see Concept: JavaBean.
JavaBean Properties
Internally, a property value can be stored as a private field, but it can be calculated as well. The designer has a
choice of pre-computing the value of the property, or use lazy evaluation, where the value will be calculated only when
asked for by a caller.
The designer also has a choice of bounding or constraining the property. If the property is bound or constrained, then
the designer must decide on the events and notification mechanism.
Events and Notification
For the implementation of the notification mechanism, the designer has two choices:
-
Use PropertyChangeSupport and PropertyChangeEvent classes from the java.beans package.
-
Create a custom notification mechanism
Classes from the java.beans package provide implementation that is applicable in most situations.
PropertyChangeEvent contains the reference to the object that fired the event, the name of the property as
String, and two objects representing the old and the new value of the property. Class PropertyChangeSupport
maintains a collection of PropertyChangeListeners and contains the code for the notification in the method
firePropertyChange.
PropertyChangeSupport is commonly used for JavaBeans that make up part of the user interfaces.
Custom notification may be appropriate where the overhead of the creation of event objects needs to be minimized. The
downside is that the implementer must implement the notification mechanism. The implementer of the custom notification
must keep in mind that a different thread may add or remove listeners during the notification process. In order to
provide for the correct behavior, most solutions create a copy of the collection that holds the listeners; the
notification is then performed using the copy. Most published implementations create such a copy at the beginning of
the notification process, which results in the creation of many clones and degraded performance. However, since
notifications are more common than listener additions or removals, a longer-lived copy can be created in advance during
the addition or removal of the listeners and then reused for notifications, providing for faster execution.
Considering productivity of developers, custom notification should be attempted only when the performance of property
change support from the java.beans package proves to be the bottleneck.
The following examples demonstrate both the use of the property change support from the java.beans package, as
well as the use of a custom notification mechanism.
Example: Tank JavaBean using java.beans.PropertyChangeSupport
Here we have a JavaBean representing a Tank, which has one bound property: level. When the level of the
Tank is changed, the Tank fires a PropertyChangeEvent which is handled by the
TankController object.
Example: Tank Java Bean using Custom Notification
In the following example, the class Tank is implemented with a custom, more efficient notification mechanism,
which avoids creation of objects during the notification.
|