When Beans are used by a visual development tool, they have to expose
their properties, methods, and events. This allows both the tool and
the user to manipulate the Bean’s appearance and behavior.
We’ve already seen this when we used BeanBox to work with the
simulator Beans: BeanBox allowed us to change property values for the
Beans, and to connect event sources with event targets. We
didn’t have to write any extra code to tell BeanBox about the
Bean’s properties and events. Instead, it relied on the Java
reflection mechanism to gather this information. We’ve actually
been providing all of the necessary information all along by
following the design patterns for properties and events when we wrote
the code for the Beans. For instance, all of the Beans we’ve
created so far have used
setPropertyName() methods for their properties.
Remember that this is the pattern for coding a read/write property.
Using these patterns allows the Java reflection mechanism to analyze
the code and determine that there is a property called
Sometimes the information that we provide implicitly using design patterns is not enough, and sometimes the reflection mechanism exposes more information than we want exposed. Of course, the reflection mechanism also forces us to follow design patterns that may not make sense all of the time. Finally, we sometimes want to expose information about our Beans that can’t be represented by the standard design patterns. ...