Keeping the Next User in Mind
When creating Beans, consider how BeanInfo, Bean properties and Customizers will help the next user understand the Bean and how it functions.

BeanInfo
Each Bean may have a BeanInfo class which is defined by the creator of the Bean. The BeanInfo class lets the application construction tools uncover information that the creator specifies about the bean, making it possible to hook up bean components through a visual programming paradigm. The creator of the Bean has complete control over how the bean is presented to programmers inside these application builders.

Tips for creating BeanInfo:

Properties
For some important Bean properties it may be useful for the Bean developer to define events that are fired when that property changes in some specific way. A special example of this is a bound property, but other events may be fired as well. When the value of one Bean's property should be extended to a property on another Bean, that is a bound property. For example, on a slider that is moving between two values, treat the current value as a bound property because turning a slide movement on a slider Bean into a setFoo on a target Bean is a convenient user model.

Not all properties should be made available as a bound property but consider whether or not some useful properties of the Bean are to be made bound. For example, a button might be made bound for its font size and type and background and foreground colors. Another example of useful bound property for a JavaBeans component is its internationalization locale: Changing the locale is likely to be of interest to other components that are interacting with this component.

The JavaBean component architecture provides support for both constrained and bound properties. This support is orthogonal so that it is possible to have a property that is constrained but not bound. In practice, Beans that export a property as constrained should also export it as a bound property; then listeners would register for both notifications. This allows a simple two-phase protocol for reacting to changes in one such property. When a property is about to change the listener is invoked through VetoableChangeListener and given an opportunity to veto the proposed change. When the change has actually happened, the (same) listener is invoked through PropertyChangeListener and the listener can react to the change.

Customizers
A Bean may need to be represented in a specific manner to users or may need to be configured in a certain sequence. Builder tools have no advance knowledge of this. By providing a Customizer the developer can address these situations. The Customizer has full access to the Bean and is normally packaged with the Bean. The Customizer can be a full-fledged JavaBeans component itself. A Customizer can set a private state of the Bean to which the property sheet and methods and events do not have access. Customizers do not override property editors. By using BeanInfo it is possible to associate property editors with Customizers.

A Customizer can encapsulate deep expertise on the use of a component, and a Customizer can be delivered independently of the Bean itself. Some JavaBeans components may even want to include different Customizers to address the needs of different customers' backgrounds, markets and level of sophistication.

Through careful consideration of these Bean characteristics, a JavaBean component developer secures a future in the emerging network software market without losing customers who use proprietary systems. By maximizing component reuse, a developer can also quickly attack new market opportunities and new ways to sell smaller packages of software.