Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Make a sweep with clean beans

Design rules that will keep your beans clean and your apps secure

By Philippe Kaplan, JavaWorld.com, 11/20/99

  • Print
  • Feedback
Classes are basic structures in an object-oriented language such as Java. Apart from syntactic and type constraints, there are no limitations as to what is a valid class and what is not. However, a class can be reused, via subclassing, and automatically processed by an application that dynamically imports objects. For these uses, the general class definition is too weak and must be refined.

Let there be beans

Beans were developed to meet this shortcoming. Upon automatic processing, beans present a predictable interface by setting more constraints on classes. If you reuse a class, you should also work with beans, because they are cleaner than general classes.

At a minimum, a bean must be serializable, and be a public class with a public zero-argument constructor. Other, optional, characteristics that improve a bean's interoperability are the ability export values, called properties, via accessors (get/set methods), and the ability to notify listeners using an event model (like AWT 1.1).

The introspection mechanism figures out a bean's events and properties according to the signature of its accessors, such as the pattern by which these methods access the events and properties. For example, the two methods String getFoo() and void setFoo(String arg) identify a string property named foo.

The bean package also specifies the BeanInfo class that describes the bean class. BeanInfo assists the code introspector while the bean is dynamically processed.

Beans define a component framework and are quite autonomous. The autonomy of a bean makes reuse and automatic processing easier, because the constraints on a bean and on its properties require that its interface be more predictable than a general class. A bean is created using the zero-argument constructor, and is customized by invoking the setter methods. Without the bean's constraints, you have to choose between the available constructors to create an instance, and find the right methods to call among all the methods provided by the class. However, even having these constraints in place is still not enough for true interoperability.

Take applets, for example. They run safely inside a browser because security constraints prevent them from damaging their hosts and user environments. In contrast, there is no such security model for beans that maintains their behavior. If a bean acts poorly, it endangers the applications that integrate it. Integrating a component safely into a program is a long-standing problem in software development. Beans do not solve it, but they can help.

Rules for clean beans

In this article, I would like to propose the concept of the clean bean, a bean which meets a minimum quality level, and which can thus be integrated and used safely in a dynamic environment.

Figure 1. Class types

Figure 1 presents the different class types. Only some classes can be considered beans, and only some beans merit the clean label. The following are the requirements that a bean must fulfill in order to be considered clean:

  • Print
  • Feedback

Resources