The Decorator Pattern is used for adding additional functionality to a particular object as opposed to a class of objects. It is easy to add functionality to an entire class of objects by subclassing an object, but it is impossible to extend a single object this way. With the Decorator Pattern, you can add functionality to a single object and leave others like it unmodified.

A Decorator, also known as a Wrapper, is an object that has an interface identical to an object that it contains. Any calls that the decorator gets, it relays to the object that it contains, and adds its own functionality along the way, either before or after the call. This gives you a lot of flexibility, since you can change what the decorator does at runtime, as opposed to having the change be static and determined at compile time by subclassing. Since a Decorator complies with the interface that the object that it contains, the Decorator is indistinguishable from the object that it contains. That is, a Decorator is a concrete instance of the abstract class, and thus is indistinguishable from any other concrete instance, including other decorators. This can be used to great advantage, as you can recursively nest decorators without any other objects being able to tell the difference, allowing a near infinite amount of customization.

Figure 1: Decorator example showing two concrete decorators that add additional state and behavior respectively.

UML diagram of a decorator design pattern example

Decorators add the ability to dynamically alter the behavior of an object because a decorator can be added or removed from an object without the client realizing that anything changed. It is a good idea to use a Decorator in a situation where you want to change the behaviour of an object repeatedly (by adding and subtracting functionality) during runtime. The dynamic behavior modification capability also means that decorators are useful for adapting objects to new situations without re-writing the original object's code. The code for a decorator would something like this:

void doStuff() {
   // any pre-processing code goes here.
   aComponent.doStuff();  // delegate to the decoree 
   // any post-processing code goes here
}

Note that the decorator can opt to not delegate to the decoree, if, for instance, some condition was not met. A very nice example of decorators is Java's I/O stream implementation.

This module is based on work originally written by Antonio Garcia

Footer

This work is licensed by Stephen Wong under a Creative Commons Attribution License (CC-BY 3.0), and is an Open Educational Resource.

Last edited by Stephen Wong on Jun 26, 2009 1:58 pm GMT-5.