Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

More on getters and setters

Build user interfaces without getters and setters

By Allen Holub, JavaWorld.com, 01/02/04

Page 3 of 6

Build a solution

This problem's solution is to separate the UI code from the core business object by putting it into a separate class of objects. That is, you should split off some functionality that could be in the object into a separate object entirely.

This bifurcation of an object's methods appears in several design patterns. You're most likely familiar with Strategy, which is used with the various java.awt.Container classes to do layout. You could solve the layout problem with a derivation solution: FlowLayoutPanel, GridLayoutPanel, BorderLayoutPanel, etc., but that mandates too many classes and a lot of duplicated code in those classes. A single heavyweight-class solution (adding methods to Container like layOutAsGrid(), layOutAsFlow(), etc.) is also impractical because you can't modify the source code for the Container simply because you need an unsupported layout. In the Strategy pattern, you create a Strategy interface (LayoutManager) implemented by several Concrete Strategy classes (FlowLayout, GridLayout, etc.). You then tell a Context object (a Container) how to do something by passing it a Strategy object. (You pass a Container a LayoutManager that defines a layout strategy.)

The Builder pattern is similar to Strategy. The main difference is that the Builder class implements a strategy for constructing something (like a JComponent or XML stream that represents an object's state). Builder objects typically build their products using a multistage process as well. That is, calls to various methods of the Builder are required to complete the construction process, and the Builder typically doesn't know the order in which the calls will be made or the number of times one of its methods will be called. Builder's most important characteristic is that the business object (called the Context) doesn't know exactly what the Builder object is building. The pattern isolates the business object from its representation.

The best way to see how a simple builder works is to look at one. First let's look at the Context, the business object that needs to expose a user interface. Listing 1 shows a simplistic Employee class. The Employee has name, id, and salary attributes. (Stubs for these classes are at the bottom of the listing, but these stubs are just placeholders for the real thing. You can—I hope—easily imagine how these classes would work.)

This particular Context uses what I think of as a bidirectional builder. The classic Gang of Four Builder goes in one direction (output), but I've also added a Builder that an Employee object can use to initialize itself. Two Builder interfaces are required. The Employee.Exporter interface (Listing 1, line 8) handles the output direction. It defines an interface to a Builder object that constructs the representation of the current object. The Employee delegates the actual UI construction to the Builder in the export() method (on line 31). The Builder is not passed the actual fields, but instead uses Strings to pass a representation of those fields.