The Decorator Design Pattern (also known as the Wrapper) By Gordon Friedman Software Design and Documentation September 22, 2003

Overview of Decorators The decorator pattern provides a viable alternative to subclassing Subclassing allows individual objects to take on responsibilities that would not normally be available to the entire class Subclassing is inflexible because the responsibilities are decided statically through inheritance Every instance of the subclass has identical responsibilities which cannot be changed at runtime The decorator allows additional responsibilities to be added to an object dynamically, circumventing the drawbacks of subclassing

Overview of Decorators The decorator object encloses a particular component and then adds responsibilities Conforms to the interface of the enclosed component creating transparency towards the clients Transparency allows many decorators to be nested recursively giving the potential of an indefinite amount of added responsibilities

Example: TextView Object The TextView Object in the diagram is the abstract class which is given responsibilities by two decorator objects aBorderDecorator draws a border around the TextView object aScrollDecorator gives the TextView object functional scroll bars

Example: TextView Object The class diagram shows that the ScrollDecorator and BorderDecorator classes are both subclasses of the abstract Decorator class

Applications of Decorators Dynamically and Transparently adds responsibilities to objects Use Decorators when you have responsibilities which can be removed Decorators can be used when subclassing becomes too complicated and involved

Decorator Class Diagram A general view of the decorator class diagram

Drawbacks of Decorators Although a decorator is transparent towards its component object, they are not identically the same Cannot rely on object identity Projects which contain Decorators often have many little objects which appear to all look alike. Programs which use Decorators are easily customized by the original programmer, but end up being extremely difficult to debug by anyone else.

Pros Of Decorators A decorator is more flexible than the inheritance alternative Responsibilities can be added and detached in run-time Retains the ability to add functionality incrementally from simple pieces Do not need to know all foreseeable features of the class before it is built

Things to Consider The decorator interface must conform to the interface of the decorated component When only one responsibility is needed, the abstract decorator class can be omitted. The decorator class would go in it’s place on the class diagram The component class should be kept low functional and focused on the interface. Data defining should be done in the subclasses. A complex component class will make decorators heavyweight and less versatile

Sample Code: Decorator Component Class called “VisualComponent”

Sample Code: Decorator Subclass of VisualComponent called “Decorator” Decorator subclass is able to reference VisualComponent through the _component variable

Sample Code: Decorator Passing functions Requests are passed to _component

Sample Code: Decorator Subclass of the Decorator class, “BorderDecorator” Specifies individual operations, draws the border on the VisualComponent Inherits all operation implementations from Decorator

References Gamma, Helm, Johnson, and Vlissides. Design Patterns. Addison-Wesley, Reading, MA, 1995 Steven Black, Design Pattern: Decorator. Antonio Garcia and Stephen Wong, The Decorator Design Pattern. ecoratorPattern.htm ecoratorPattern.htm

Any Questions?