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

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/JavaResources/DesignPatterns/DecoratorPattern.htm

16. Any Questions?