Why has the accessor methods from the JavaBean specification become the standard for Java development?

Question

The JavaBeans Specification describes a JavaBean as

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

Since the majority of the lines of code that are written seem to have nothing to do with being manipulated visually in a builder tool, why has the JavaBean specification been the "way" to write object oriented code?

I would like to forgo the traditional getter/setter in favor of Fluent Interfaces all throughout the code, not just in builders but fear doing so since this is traditionally not the way way object oriented code is written in Java.

Answer 1

JavaBean style accessors have proven to be a good match for all kinds of scenarios that are similar to the original "builder tool" scenario in one core point: components are being passed around and manipulated by generic containers and tools as well as application code. In an app server you have service components to which an EJB or Spring container adds transactions and dependency injections, persistent domain models to which an ORM adds lazy loading and change detection, and which can be serialized to XML by a library without any specific code.

Accessors provide a common API that is very flexible in how the component can be used - it does not proscribe an order of operations. Each accessor call is independant of others and they all follow the same pattern, so you can easily add generic layers that add functionality without disrupting the intended usage pattern.

In contrast, fluent interfaces are often designed for one-shot use: the object is created, a chain of methods is called that ends with a method that produces a final result, and the object is then abandoned. There is much less flexibility (mostly in methods being optional) and genericality, but this is exactly the advantage: the interface forces you into an intended usage pattern, making it very easy to use.

So JavaBeans and fluent interfaces have advantages in different scenarios, and which you should use depends. And you could even combine both.

Answer 2

Well, because the JavaBeans Specification you link to defines a convention for accessing properties, folks decided to take advantage of the convention and built frameworks around it. Some of these frameworks, such as Hibernate, were quite useful and so became very popular. So, because people used frameworks that were based on the JavaBeans spec, javaBeans became more and more ubiquitous, and more and more frameworks were built around them.

Fluent Interfaces are a great idea, but do they play well with Spring or Struts 2? Beats me.