Bean Introspection  «Prev 

What are Boolean Property Design Patterns?

Although they technically are simple properties, boolean properties have an optional design pattern for the getter method that can be used to make it more clear that the property is boolean. The design pattern for the boolean getter method follows:

public boolean isPropertyName();

The only difference between this design pattern and the one for simple properties is that it uses the word is instead of get in the method name.
Following is an example of a pair of accessor methods for a boolean property named visible:

public boolean isVisible();
public void setVisible(boolean v);

You might be curious as to what happens if both a get method and an is method are defined for a boolean property. JavaBeans handles this potentially confusing situation by always using the is method if it is available, and the get method if not.

Boolean Properties

In addition, for boolean properties, we allow a getter method to match the pattern: public boolean is <PropertyName>(); This is<PropertyName> method may be provided instead of a get<PropertyName> method, or it may be provided in addition to a get<PropertyName> method. In either case, if the is<PropertyName> method is present for a boolean property then we will use the is<PropertyName> method to read the property value. An example boolean property might be:
public boolean isMarsupial();
public void setMarsupial(boolean m);

Indexed properties

If we find a property whose type is an array <PropertyElement>[], then we also look for methods of the form:
public <PropertyElement> get<PropertyName> (int a);
public void set<PropertyName>(int a, <PropertyElement>  b);
If we find either kind of pattern then we assume that >propertyName> is an indexed property and that these methods can be used to read and/or write an indexed value. Thus an indexed property "foo" might be represented by four accessor methods:
public Bah[] getFoo();
public void setFoo(Bah a[]);
public Bah getFoo(int a);
public void setFoo(int a, Bah b);

Design Patterns for Events

By default, we use the following design pattern to determine which events a bean multicasts. We look for a pair of methods of the form:
public void add <EventListenerType>(<EventListenerType> a)
public void remove <EventListenerType>(<EventListenerType> a)
where both methods take the same <EventListenerTyp> type argument, where the <EventListenerType type> extends the java.util.EventListener interface, where the first method starts with add, the second method starts with remove, and where the <EventListenerType> type name ends with Listener. This design pattern assumes that the Java Bean is acting as a multicast event source for the events specified in the <EventListenerType> interface. So for example:
public void addFredListener(FredListener t);
public void removeFredListener(FredListener t);

defines a multicast event source.