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 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/D ecoratorPattern.htm http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/D ecoratorPattern.htm

16. Any Questions?