JavaBean Property State

Like normal Java objects, Beans have an internal state that affects their appearance and behavior. In normal Java objects, data can be declared public and is accessible to outside objects or applications. A piece of public Bean data has a special significance and is known as a property ^[1].

Unlike public data in normal Java classes, properties aren't declared public in Beans because they must be accessed through a formal interface.
Properties are very important to Beans because they represent one of the primary means in which users interact with Beans at design time.

• Customizing JavaBeans at Design time: Bean properties are modifiable at design time through visual property editors or through straight coding. By altering property values, an application developer can customize both the appearance and behavior of Beans. This customization is carried out either visually or programmatically, depending on the development tools being used. Bean customization is covered later in this course.

It is certainly possible that you would want to design a Bean that behaved differently at design-time than it does at run-time. Maybe the Bean does an enormous amount of processing, or it has some other feature that just doesn't lend itself well to a design-time environment. A development tool can call the

setDesignTime() 

method on the java.beans.Beans class to indicate whether or not the system is running in design mode. In turn, your Bean can call the isDesignTime() method on the same class to find out if it is running in design mode. This call could be made at the time the Bean is instantiated and stored in a variable. This way the Bean can always check the state of this variable before performing a function that is dependent upon whether it is running in design mode.
The problem is that some development tools may be able to switch between design-time mode and run-time mode on the fly, without having to create different instances of the Bean. The current JavaBeans architecture does not provide a way for Beans to listen for changes in the design mode. Therefore, even though you can get this information at any time by calling isDesignTime(), you have no way of knowing if and when you should be calling it. Depending on the development tool you are using, this could be a real problem. Hopefully, future versions of the JDK will allow Beans to become event listeners for changes to the design mode status.

Even though properties often represent built-in Java data types such as int and long, they also can represent class and interface types. In this way, a property can really be any data type you choose, including your own custom types. Properties can also be computed values based on other properties or pieces of information.

• JavaBean Properties Properties are discrete, named attributes of a Java Bean that can affect its appearance or its behaviour. For example, a GUI button might have a property named “Label” that represents the text displayed in the button. Properties show up in a number of ways:
  1. Properties may be exposed in scripting environments as though they were fields of objects. So in a Javascript environment I might do "b.Label = foo" to set the value of a property.
  2. Properties can be accessed programmatically by other components calling their getter and setter methods
  3. As part of the process of customizing a component , its properties may be presented in a property sheet for a user to edit.
  4. Typically a bean's properties will be persistent, so that their state will be stored away as part of the persistent state of the bean.
  Properties can have arbitrary types, including both built-in Java types such as "int" and class or interfaces types such as "java.awt.Color".

Properties are attributes of a Bean that are referenced by name and these properties are usually read and written by calling methods on the Bean specifically created for that purpose. A property of a thermostat component could be the comfort temperature. A programmer would set or get the value of this property through method calls, while an application developer using a visual development tool would manipulate the value of this property using a visual property editor.
The methods of a Bean are just the Java methods exposed by the class that implements the Bean. These methods represent the interface used to access and manipulate the component. Usually, the set of public methods defined by the class will map directly to the supported methods for the Bean, although the Bean developer can choose to expose only a subset of the public methods.
Events are the mechanism used by one component to send notifications to another. One component can register its interest in the events generated by another. Whenever the event occurs, the interested component will be notified by having one of its methods invoked. The process of registering interest in an event is carried out simply by calling the appropriate method on the component that is the source of the event. In turn, when an event occurs a method will be invoked on the component that registered its interest. In most cases, more than one component can register for event notifications from a single source. The component that is interested in event notifications is said to be listening for the event.
In the next lesson, properties and Bean state will be discussed.

[1] : Property: a discrete, named attribute of a Bean that determines its appearance and behavior.