JavaBeans
From Wikibooks, the open-content textbooks collection
Contents |
[edit] The JavaBeans Component Model
JavaBeans, the mainstream Java component Model, was introduced in 1996 by Sun Microsystems. It takes into account most important characteristics which constitute a component. JavaBeans are defined as follows:
"A Java Bean is a reusable software component that can be manipulated visually in a builder tool."
Together with the component model, Sun released a simple visual composition tool, the BeanBox. It is rather intended for experimenting with Beans than offering a professional IDE. For real world applications, one should better fall back on one of the Java IDEs like Visual Age or JBuilder that support the visual composition of JavaBeans, too.
As we can see, JavaBeans do not necessarily differ much from standard Java classes. That makes the beans component model quite easy to use. But JavaBeans can have some features most normal Java classes do not have:
- Persistence
- Properties
- Introspection
- Event Communication
- Customization
[edit] Persistence
The requirements for an object to be a bean is to define a public parameterless constructor, so that beans can be instantiated by builder tools in an uncomplicated way (In the Point bean, the parameterless constructor is given implicit). Secondly, one of the interfaces {\code java.io.Serializable} or {\code java.io.Externalizable} need to be implemented. The interfaces do not prescribe the implementation of any methods, but are an approval, that the bean may be saved in persistent storage as in a file or database. In doing so, the bean can be restored after an application was shut down or transferred across networks. The ability to store state of a component in persistent storage is called persistence. Java offers a standard serialization mechanism, what makes it very easy to serialize objects. Alternatively, component can be stored in a customized manner (e.g. in xml format) by implementing the {\code Externalizable} interface.
[edit] Properties
The properties of a bean are all fields that are accessible and modifiable by public methods. These getter and setter methods should be marked as such by following a certain naming scheme:
<PropertyName>(PropertyType).
The accessor methods, on the other hand, are programmed by the pattern
public PropertyType get<PropertyName>()
[edit] Introspection
The intention behind this naming convention is that it helps builder tools to find out how a bean works and what capabilities it has. As we have seen, a component has to provide information about its services, which is called introspection. Java Beans provides two mechanisms for introspection: reflection and the {\code BeanInfo} class. BeanInfos gives complex information about a Bean component, but have to be implemented explicitly.
[edit] Events
JavaBeans interact with each other by means of events. Events are notifications, a component can give to other components, that something interesting has happened. An example for an event might be a mouse click on a button or the closing of a window. Beans can be source and target of events. To be informed about an event, a bean has to register at another Bean as a listener.
The Java event model realizes the observer design pattern with the effect that the inter-component coupling is reduced. Method calls require tight coupling, as caller and receiver need to know each other at compile time, while with events all communication happens solely via interfaces.
A special kind of event are {\code PropertyChangeEvents}. They are used to restrict some properties to take only specific values, for example for a month integer values between 1 and 31. Every time, such a bound property is modified, notifications to all registered PropertyChangeListeners will be send.
[edit] Customization
Customization is done via Property Editors. A property editor is a tool for customizing at design time a particular property type. Property editors are activated from so-called property sheets, which display all properties of a bean. If a property is selected for customization, the property sheet finds out the type of the property, displays the appropriate property editor with the property's current value.
[edit] Final Remarks
A big strength of the javabean component model is that it is designed for simplicity. Developing JavaBeans is very simple, because a lot of behaviour (like the platform independence or packaging mechanism) is supported in the Java Programming Language by default. However, one can optionally equip beans with additional objects like BeanInfos or custom PropertyEditors to use the component model in a more flexible way. A second facility is that Sun designed the whole swing GUI library according to the JavaBeans component model. Thereby Swing components can easily be composed in visual builder tools.
However, JavaBeans do not realize all features of a component model. A drawback is that JavaBeans are restricted to the Java programming language, while an important goal of components the independence of an implementation language is. {{LOC|QA76
