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:

Posted in Design Pattern, Swing Design Pattern | Tagged , , , | 6 Comments

6 Responses to Swing and Design Patterns – Part 1. Decorator Pattern

  1. vikas says:

    Hi Mate,

    I could connect with it very easily. You explained decorative design pattern beautifully with a real world example.

    Thanks,

  2. lee says:

    great series on swing and design patterns. when would part 4 be available?

  3. yousuf says:

    Delicious explanation..!!

  4. George says:

    Hi felixzacat,

    Thank you for sharing your insight for this design pattern. Simple and clear the example you made, straight to the point of the design pattern. All is good up the point of the decorator to be used in a table that uses reflection. I have that implementation of a generic tablemodel, that analyzes the class object, retriving all the getters and setters from the object and by method invocation gets the corresponding value. Along with this generic model, I use ORM modeling for my classes/entities. So if I get this right, I can use this pattern, to pass in the decorator the entity to be displayed in a table, but pass the decorator class into my tablemodel, analyze that class, that may hide for example associations to collections in my entity, or any other fields I do not want to be displayed. Also, that would be a much quicker way, since now my class analyzer recurses into any associations that are not of any primitive type (String, int, etc), which takes a long time to recurse, since ORM modelling creates many associations from one entity to another plus reverse associations and so on and so on…So by doing this I can void this long recursion. If you comment on this it would be much appriciated. Thank you once more.

  5. felixzacat says:

    Hi @George I will reply on Monday. Don’t have time at the moment :)

  6. George says:

    Hi @felixzacat, I am following up on my last question, to see if you had a chance to take a look at the question I posted a few days ago. I tried to figure out the question by doing some testing on my own, I have some ideas but I am not sure if I move in the right direction. If you have time I would appriciate any comments. Thank you once more. :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

THREE_COLUMN_PAGE