Data Retrieval Patterns: The JavaBean Pattern

The JavaBean is the standard pattern for creating plug-and-play Java components for external or disassociated infrastructures. All data is private and retrieved by getters - named with get followed by the capitalised field name. A getter has no parameters. Fields can be set by the constructor or with a setter - named with set followed by the capitalised field name.

class MyJavaBean
  {
    private int integer;
    public int getInteger()
      { return integer; }
    public void setInteger( int integer)
      { this.integer = integer; }
  }

 

JavaBean's Strengths

1. Provides a consistent interface for factories and other component based systems (such as plug-and-play GUI components). BSF?
2. A well known pattern with strong IDE support.
3. Requires data to be private, accessed only by getter and setter methods.
4. Internals can be changed without affecting users of the bean. Local data can be lazy-loaded from a properties file, for example.

JavaBean's Weaknesses

1. As all fields with public access require getters and setters, JavaBean means significant code bloat.
2. No differentiation between simple local data access and more complex/time consuming data retrieval.
3. Points of usage are less readable with the inclusion of get and () to the field name.
4. Private data isn't actually protected, since setters need to be public to be used.

JavaBean's Uses

1. Where JavaBeans were meant to be used – as plug-and-play components in a separate infrastructure;
2. and where they aren't – wherever bureaucracy dictates when working for enterprise clients. Sigh.
3. Where you have a framework (such as Groovy) that make JavaBeans as easy to use and as concise as public data. Groovey, like Perl, triggers a getter or setter method call when you attempt to reference the data directly. Unlike Perl, the triggering is not optional.