Java Practices->Avoid JavaBeans style of construction

Avoid JavaBeans style of construction

Some argue that to construct a Model Object in many steps, first by calling a no-argument constructor, and then by calling a series of setXXX methods, is something to be avoided, if possible:

it's more complex, since one call is replaced with many
there is no simple way to ensure that all necessary setXXX methods are called
there is no simple way to implement a class invariant
it allows the object to be in intermediate states which are not immediately useful, and perhaps even invalid
it's not compatible with the (very useful) immutable object pattern
it does not follow the style of many design patterns, in which concrete classes usually have arguments passed to their constructor. This is a recurring theme in the Design Patterns book. Constructors usually act as a "back door" for data which is needed by an implementation, but which cannot appear in the signature of some higher-level abstraction (since it would pollute such an abstraction with data specific to an implementation).

Of course, JavaBeans follow this pattern of "no-argument constructor plus setXXX". However, JavaBeans were originally intended for a very narrow problem domain - manipulation of graphical components in an IDE. As a model for the construction of typical data-centric objects (Model Objects), JavaBeans seem completely inappropriate. One can even argue strongly that, for Model Objects, the JavaBeans style is an anti-pattern, and should be avoided unless absolutely necessary.

"The JavaBeans pattern has serious disadvantages." - Joshua Bloch, Effective Java

If you need more convincing, read on.

Here is the definition of a Java Bean, directly from the original specification:

"A Java Bean is a reusable software component that can be manipulated visually in a builder tool."

This is very clear and simple. No mention is made here, or anywhere else in the specification, of Model Objects used to encapsulate database records. The whole idea of a Model Object is entirely absent from the Java Bean specification, and for good reason: the manipulation of graphical controls and the representation of database records are unrelated issues.

The life cycle of a Java Bean, starting with its no-argument constructor, is derived mainly from the task of configuring a graphical control having some default initial state. For the intended domain, this is indeed a reasonable design. For Model Objects, however, the idea of configuration in this sense is entirely meaningless.

The role of a Model Object is to carry data. Since a no-argument constructor can only build an object that is initially empty, then it cannot contribute directly to this aim. It does not form a natural candidate for the design of a Model Object.

To put data into empty Java Beans, frameworks typically call various setXXX methods using reflection. There is nothing to prevent them from calling constructors in exactly the same way.

A demonstration that a framework does not need JavaBeans for its Model Objects is found in the WEB4J tool. WEB4J calls (surprise, surprise) a constructor to build Model Objects. It recommends implementing Model Objects as immutable objects, not Java Beans.

The widespread adoption of Java Beans as a supposedly appropriate design for Model Objects seems to be an error.