Javabeans: an anti-pattern or not?

What a strong title!

There is a lot of misconceptions about javabeans. Current trend is: javabeans are an anti-pattern. And this is in part true. But I prefer to analyze all the issues related to them, so  anyone can have an overall knowledge of what javabeans are and what are not.

First of all let’s see what is a Javabean:

Javabean is only a specification, quoting wikipedia:

In order to function as a JavaBean class, an object class must obey certain conventions about method naming, construction, and behaviour. These conventions make it possible to have tools that can use, reuse, replace, and connect JavaBeans.

The required conventions are as follows:

• The class must have a public default constructor (no-argument). This allows easy instantiation within editing and activation frameworks.
• The class properties must be accessible using get, set, is (used for boolean properties instead of get) and other methods (so-called accessor methods and mutator methods), following a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties. Setters must receive only one argument.
• The class should be serializable. It allows applications and frameworks to reliably save, store, and restore the bean’s state in a fashion independent of the VM and of the platform.

Now let’s see a classical example of a java bean:

package it.nicogiangregorio.reactor;

import java.io.Serializable;

public class Employee implements Serializable {
 private String firstName;
 private String lastName;
 private String employeeId;
 private boolean isManager;

public Employee() {}

public String getFirstName() {
 return firstName;
 }

public void setFirstName(String firstName) {
 this.firstName = firstName;
 }

public String getLastName() {
 return lastName;
 }

public void setLastName(String lastName) {
 this.lastName = lastName;
 }

public String getEmployeeId() {
 return employeeId;
 }

public void setEmployeeId(String employeeId) {
 this.employeeId = employeeId;
 }

public boolean isManager() {
 return isManager;
 }

public void setManager(boolean isManager) {
 this.isManager = isManager;
 }
}

This is a very simple class, representing an Employee with 4 very basic properties:

• first name;
• last name;
• employee identifier;
• isManager: whether the employee is a manager or not;

Criticism to Java beans

While Java beans are very common and omnipresent in java code base, there is a bunch of aspects to take into consideration about them.

Most of the OOP purists consider them very harmful to source code of any application and claim that Java beans violate some of basic principles of Object Oriented Programming. So nowday it is very common to listen to “java beans is an anti-pattern”.

Ok, but why? What are the principles java beans violate?

This little snippet of code:

Employee employee = new Employee();

Instantiate a new object called employee with the base constructor from java-bean previously defined.

While this is very common, this creates an empty object, with an inconsistent state.

OOP principles assert that every object must own a valid state, but in our case what does employee represent?

It is an empty employee with no properties, so the answer is: NOTHING.

An employee object has a sense only if there is an associated employeeId or with the pair firstName – lastName.

So a valid constructor may be:

Employee employee = new Employee(employeeId)

Or

Employee employee = new Employee(firstName, lastName)

Furthermore, the constaints of define an accessor and mutator method for each property creates a lot of boilerplate.

And the last, but not the least: Javabeans make a class mutable even if it is not strictly necessary. So javabeans require an extra effort in handling thread-safety (an immutable class is always thread safety!).

Advantages of Javabeans

There is a very simple and valuable advantage of javabeans: is a convention.

While it may seem very poor motivation, this is, imho, very important. Many people complain about Java fragmentation, and they are right:

too many frameworks, too many ways of doing the same thing, too many parties. Javabeans seem to accord everyone and represent a common feature all over the java world.

Here a very incomplete list of java frameworks\API, adopting java beans:

– JSF;

– Jersey;

– Jaxb;

– Struts;

– DWR;

– JSP;

– JAX-WS;

..and many other.

Conclusion

In my opinion, while Javabeans are very controversial and violate some common and widely adopted design principles, they are a very useful convention between java frameworks. So my suggestion is use them judiciously:

if a framework requires Javabeans, don’t be scared to use them, but don’t abuse it, don’t create a class with multiple responsibility and mask it as a javabean, that is only a lie.

Don’t call extra business logic within javabean and restrict their adoption only as a mutable representation of an entity in your domain.