Simple Property Design Patterns
Simple properties in JavaBeans consist of all single-valued properties, which include all built-in Java data types as well as classes and interfaces.
For example, properties of type int, long, float, Color, Font, and boolean are all considered simple properties.
The design patterns for simple property accessor methods follow:
public PropertyType getPropertyName();
public void setPropertyName(PropertyType x);
Applying these design patterns to a property of type long named quota would yield the following method definitions:
public long getQuota();
public void setQuota(long q);
Simple Properties
By default, properties are determined from get/set access method combinations that follow a prescribed naming convention:
public void setXXX(TYPE value);
public TYPE getXXX();
The name of the property is the common part of the get/set method names, that is,
the characters following "get" or "set".
For the StickFigure Bean, mood (happy or sad) could be a property:
public void setMood(int mood){
this.mood = mood;
repaint();
}
public int getMood(){
return mood;
}
By default, IDEs analyze Beans for all conforming properties, organize them in a property sheet, and automatically handle the data conversions required to display their values and process modified values.
For example, an integer property is typically converted to a string and displayed in a text field widget.
When the value is updated via the property sheet, the IDE must convert the new value to an integer and invoke the appropriate set method.
The IDE facilities for managing these property updates are called property editors.
Most IDEs provide several built-in property editors.
The previous example illustrates a common property type issue. IDEs provide property editors for common
data types. With a property such as mood, the best data types for representing its range of
values are often strings or integers. String handling can be quite messy programmatically and, in an IDE,
string data types for discrete-valued properties are subject to incorrectly typed (misspelled) values.
For this reason, programmers often use integers for properties with discrete values:
public static final int HAPPY = -1;
public static final int SAD = -2;
...
private int mood = HAPPY;
...
For programmatic manipulation of a Bean, this design works well, but for design-time manipulation in an IDE,
having to know that happiness is represented by -1 compromises the higher level approach to building
applications. For properties such as mood, the preferred technique is to design a custom property editor that accompanies the Bean class, which is discussed subsequently.
For completeness, two secondary issues related to naming conventions should be mentioned.
First, the JavaBeans model does not preclude read-only and write-only properties, identified by get-only and set-only access methods, respectively. However, one-way properties are rather uncommon, and, of course, cannot support the typical display-and-update behavior in a property sheet. The second issue has to do with a second type of property, indexed properties.