Bean Introspection  «Prev  Next»
Lesson 3Understanding introspection design patterns
Objective How are design patterns used to provide automatic introspection capabilities?

Understanding Introspection Design Patterns

By conforming to simple design patterns, Bean developers can create Beans that fully support introspection by default, without doing any extra work.
Introspection design patterns are nothing more than a naming convention for the public methods of a Bean, but they play a pivotal role in JavaBeans since they are responsible for providing a default, automatic form of introspection.
This type of introspection is automatic because JavaBeans analyzes the naming and type signatures for public methods in a Bean to determine what properties, methods, and events the Bean makes available for public use.
Design patterns: standardized naming conventions and type signatures for Bean methods that are used to convey information about a Bean.
In the next lesson, various types of design patterns will be discussed.

Overview of Design Patterns

By the term design patterns we mean conventional names and type signatures for sets of methods and/or interfaces that are used for standard purposes. For example the use of getFoo and setFoo methods to retrieve and set the values of a "foo" property. These design patterns have two uses. First they are a useful documentation hint for human programmers. By quickly identifying particular methods as fitting standard design patterns, humans can more quickly assimilate and use new classes. Secondly, we can write tools and libraries that recognize design patterns and use them to analyze and understand components.
In particular for Java Beans we use automatic identification of design patterns as a way for tools to identify properties, events, and exported methods. However, within Java Beans the use of method and type names that match design patterns is entirely optional. If a programmer is prepared to explicitly specify their properties, methods, and events using the BeanInfo interface then they can call their methods and types whatever they like. However, these methods and types will still have to match the required type signatures, as this is essential to their operation.
Although use of the standard naming patterns is optional, we strongly recommend their use as standard naming conventions are an extremely valuable documentation technique.

What all three kinds of beans have in common are certain naming paradigms. All public properties should be accessible by get/set accessory methods. For a given property Prop of type Type, the following two methods should exist (note the capitalization):
public Type getProp( );
public void setProp(Type)

For example, the various AWT and Swing components that have textual labels all have the following pair of methods:
public String getText( );
public void setText(String newText);

You should use this set/get design pattern (set/get methods) for methods that control a bean. Indeed, this technique is useful even in nonbean classes for regularity. The "bean containers",
  1. the Bean Builders,
  2. the JSP mechanism, and
  3. the EJB mechanism
all use Java introspection to find the set/get method pairs, and some use these to construct properties editors for your bean. Bean-aware IDEs, for example, provide editors for all standard types (colors, fonts, labels, etc.). You can supplement this with a BeanInfo class to provide or override information. The bare minimum a class requires to be usable as a JavaBean in a GUI builder is the following:
  1. The class must implement java.io.Serializable.
  2. The class must have a no-argument constructor.
  3. The class should use the set/get paradigm.
  4. The class file should be packaged into a JAR file with the jar archiver program