The Decorator Design Pattern (also known as the Wrapper)

1
The Decorator Design Pattern(also known as the
Wrapper)

• By Gordon Friedman
• Software Design and Documentation
• September 22, 2003

2
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

3
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

4
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

5
Example TextView Object

• The class diagram shows that the ScrollDecorator
  and BorderDecorator classes are both subclasses
  of the abstract Decorator class

6
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

7
Decorator Class Diagram

• A general view of the decorator class diagram

8
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.

9
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

10
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 its 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

11
Sample Code Decorator

• Component Class called VisualComponent

12
Sample Code Decorator

• Subclass of VisualComponent called Decorator
• Decorator subclass is able to reference
  VisualComponent through the _component variable

13
Sample Code Decorator

• Passing functions
• Requests are passed to _component

14
Sample Code Decorator

• Subclass of the Decorator class,
  BorderDecorator
• Specifies individual operations, draws the border
  on the VisualComponent
• Inherits all operation implementations from
  Decorator

15
References

• Gamma, Helm, Johnson, and Vlissides. Design
  Patterns. Addison-Wesley, Reading, MA, 1995
• Steven Black, Design Pattern Decorator.
  http//www.stevenblack.com/Articles/PTN-Decorator.
  asp
• Antonio Garcia and Stephen Wong, The Decorator
  Design Pattern. http//www.exciton.cs.rice.edu/Jav
  aResources/DesignPatterns/DecoratorPattern.htm

16
Any Questions?