Developing Java Beans

Chapter 9. Introspection

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 getPropertyName() and 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 PropertyName.

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. ...