Lesson 8

Reusable Components and Java Beans

What is a Java Bean?
It is a reusable software component that can be visually manipulated in builder tools. To understand the precise meaning of this definition of a Bean, clarification is required for the following terms:

1. Software component
2. Builder tool
3. Visual manipulation

Software Component

To understand what reusable components are, let's deviate a bit from software and focus on the component approach to hardware. If you asked an electrical engineer to assemble a computer, he would find it to be an easy job. All the hardware components are readily available; all you have to do is purchase the necessary components from the vendors and assemble them, then, a computer is ready in just a few days. You simply need to know the interface and functionality of each hardware component treating each component as a "black box;" you're concerned with what it does, but not how it does it -- and you need some assembly knowledge.

This component approach to hardware can be applied to software. JavaBeans is a reusable software component architecture, like VBX (Visual Basic Extensions) or OCX (OLE Controls). JavaBeans components -- beans -- are separate code modules, written at the source level, that an application developer can use to combine into larger applications. And, unlike VBX or OCX, the advantage of JavaBeans is that it's a cross-platform architecture that's tied closely to Java.

Classes Into Beans

You can make any Java class into a bean just by changing the class to adhere to the JavaBeans specification. It's up to you to decide what you want to design as a bean and what you want to design as a Java class: It's a good idea to leave all the library classes as Java classes, but graphical user interface (GUI) elements can be designed to be beans, and some beans such as beans on a server can be non-GUI-related.

Not every Java class you create should be turned into a bean. Here are a few questions that may help you determine whether to convert a Java class into a bean:

   - Can this piece of code be used in more than one area? Would others benefit from reusing this piece of code?
   - Can you quickly think of ways that this piece of code might be customized?
   - Is the purpose of this code easy to explain?
   - Does the code module contain all the information it needs to work by itself?
   - Does it have good encapsulation?

If you can answer "yes" to most of these questions, you should make the class a bean.

Basic Javabean Concepts

Regardless of its functionality, every bean should support the following characteristics and behavior:

A. Persistence. Since a bean must be customizable, it must be able to save and restore its customized values. Every bean must implement the Serializable interface so that it will know how to save its state and restore it automatically. No further special handling is generally needed, since all AWT components know how to serialize themselves. Because a class that implements Serializable is serialized into an inactive state, it is not necessary to serialize a class's active states. For example, there's no point in serializing a thread. So all the states that should not be serialized should be marked transient.

   class MyBeanClass implements Serializable{
     transient Thread t; //thread information not to be serialized
     //no-arg constructor
     public myBean(){}

A bean should have at least one "no-arg" constructor. It's OK to have other kinds of constructors, but a bean needs at least one constructor that has no parameters. This is necessary because Class.newInstance(), which is called to create a new instance of a bean, needs a no-arg constructor. Similarly, all subclasses and uses of them should be marked transient if their parents are not serializable; otherwise, you'll have compilation problems.

B. Visual manipulation. A bean should allow visual manipulation of its properties. Beans support get and set methods to manipulate properties. The definition of properties is based on the design pattern (naming convention) of the methods defined in the class. The general syntax is getProperty() and setProperty() to get or set a property named Property.

For example, a bean that provides a method declared as DataType getProperty() is exposing a property named Property of type DataType. Similarly, a bean that provides a method declared as setProperty(DataType x) is allowing visual manipulation of a property named Property of type DataType. The actual property (the internal variable name) and the property named Property need not match. The property name should be meaningful to the application developer.

C. Introspection. Beans should support the introspection mechanism, which allows the application builder to analyze how the bean works. To support introspection, beans must obey design patterns, or naming conventions. (The get and set methods as declared above obey JavaBeans design patterns.) If the application builder can understand the JavaBeans introspection mechanism, it is able to analyze the bean automatically using the Reflection API. Another way to let the application builder know what the bean supports is to provide a bean information class along with the bean package. If the bean information class throws an exception, the application builder will automatically revert to the introspection mechanism to find the bean's properties.

D. Events. Beans should be able to fire off events. To support this behavior, a bean must also provide methods for registering and unregistering listeners. The general syntax is as follows:
nbsp;nbsp;nbsp;addTypeListener(TypeListener l);
nbsp;nbsp;nbsp;removeTypeListener(TypeListener l);

This code indicates that beans can fire off events of type TypeEvent. Beans use the delegation event model to fire off events.

E. Customization. Beans should also provide mechanisms for customization that would alter their appearance or behavior.

When application developers visually manipulate your bean, they do so by using the default property sheet. But this can be difficult and unclear, especially with complex beans. In such a case, you can provide a customized property sheet (for example, a GUI-based frame with images and whatnot) that visually tells the application developer what is changing. Providing such a property sheet in your bean is called customization.
Customization is provided through a Customizer class (present in the beans package), which you later package along with the bean. If your bean supports customization, you can use this advanced GUI-based property sheet by selecting Customize from the Edit menu in the Bean Development Kit. Manipulating the customizer window automatically changes your bean property.
Once you develop a bean, you need to package it as a JAR (Java archive) file.

The two applets below are an
example of applet communication.

Your browser does not support Java. Download Netscape or IE 3.0 or better Your browser does not support Java. Download Netscape or IE 3.0 or better


Assignment 8

- Write a program (bean) that does metric to imperial (and imperial to metric) measurement conversions.
Do at least weight, and length conversions.

Return to the Top