Understanding Introspection Design Patterns

By conforming to simple design patterns^[1], 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.

At first, the concept of JavaBeans analyzing the methods for a Bean to determine the Bean's behavior might seem a little strange. However, the premise behind this approach to introspection is that method names and signatures generally conform to a standard convention, sometimes by accident, but more often by virtue of class organization. In other words, Java developers generally use the same naming conventions for methods that perform a common function such as accessing a property or registering an event listener. Design patterns take this idea a bit further by enforcing a standard naming convention for all developers to adhere to. In doing so, design patterns alleviate the need for developers to explicitly provide introspection information about their Beans.
To learn more about design patterns visit gofpattern.com

Reflection is a feature of the Java programming language that allows a program to examine and manipulate its own code, including class structures, fields, and methods, at runtime.JavaBeans is a Java specification for a software component that has been designed to be easily reusable, with properties, methods, and events that can be wired together in a container to build a more complex system.
The relationship between Reflection and JavaBeans is that Reflection is often used in conjunction with JavaBeans to inspect and manipulate the properties of a JavaBean at runtime. This enables dynamic discovery and manipulation of the attributes and behaviors of JavaBeans components, making it possible to build highly configurable systems using JavaBeans and Reflection.

1. Reflection is the third indispensable API (java.lang.reflect) for the JavaBeans Architecture.
   With reflection, it is straightforward to examine any object dynamically, to determine (and potentially invoke) its methods.
2. IDE examines a Bean dynamically to determine its methods,
   1. analyze design patterns in method names and put together a list of access methods that retrieve and set instance data,
   2. for example, getForeground() and setForeground() for retrieving and setting foreground color.
   3. An instance/state variable with this type of access methods is called a property.
3. IDE uses reflection to determine the properties of the Bean
   1. presents them for editing in a graphical window, (property sheet).
   2. By using standard naming conventions a programmer can design a Bean that's configurable in a graphical builder tool.

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

[1] Design patterns: standardized naming conventions and type signatures for Bean methods that are used to convey information about a Bean.