Swing and Design Patterns – Part 1. Decorator Pattern

I am going to talk a little about my experiences with design patterns, specifically when building a Swing application.

Being the visual guy that I am, I decided to put together a little visual schematic showing the four most important (in my opinion) design patterns that should be applied when building your typical Java Swing application :

They are :

• Mediator Pattern
• Command Pattern
• Delegate Pattern
• Decorator Pattern

In this first part, out of the proposed four part blog, I am going to talk about the decorator pattern.

Decorator Pattern

The decorator pattern can facilitate the rendering of a business model bean in the context of the MVC pattern. The decorator wraps or masks the bean and can present the bean in a certain way for a particular GUI component.

The pattern deals with ‘decorating’ a business model bean with one or more decorators. The decorators can add, remove, enhance or modify properties of the bean they are masking. This reduces work that a renderer (the View) might need to do.

Examples what a decorator might do :

• Modify the formatting of a date.
• Derive an extra field. Eg: Age from date of birth
• Hide unnecessary fields (useful when doing data binding on, for example, a table)

The decorator pattern can also be used to enhance GUI components (in the context of painting over), although I won’t be talking about that here.

The classic approach is to have an interface defined like this :

A normal business bean called Patient.java will implement this interface. A decorator class will also implement this interface, such as in the following code :

Decrorator Pattern and Tables

The decorator pattern is very useful when used with Swing tables. In the above example the decorator functions as a wrapper. An extra column called ‘Age’ can be added to the table and render this newly derived field, using the appropriate wiring in the table model.

If the derived field requires a lot of processing then it can perform its processing during object construction, storing its value in a new field. This new field can then be accessed just like all the other values. For example:

This reduces the work that the cell rendering has to do, which can be intense if a user is often scrolling through a table.

 

Hiding Fields?

Although the classic approach in using the decorator pattern uses a common interface between the bean and decorator; I find that sometimes that is unnecessary.

It is sometimes sufficient to pass the bean through the constructor. Using the pattern this way allows the hiding of unwanted fields, for example maybe in our table example we don’t care about date of birth, however we want to show the patient’s age.

NOTE: Hiding fields is especially useful using databinding : Especially when databinding uses reflection on all the getter methods.

 

 

 

 

Decorate your Tree

Decorators can be used when displaying data in JTrees :

In the above example the decorator is also responsible for organizing representation of its internal bean in the form of a tree branch structure. The method getPatientNodeBranch() can be used when attaching the object to a tree node like this :

The decorator pattern (using a common interface) allows for the nesting of decorator implementations. You could have a decorator for your table, and have this nested inside your decorator for your tree.

Further reading:

Swing Delegate Pattern Swing Command Pattern Swing Mediator Pattern