Guidelines: Designing JavaBeans
Topics
Introduction
This guideline focuses on designing JavaBeans and different choices a designer
can make.
For more information on JavaBeans, see Concepts:
JavaBeans.
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.

|