The Decorator Design Pattern also known as the

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: Text. View Object • The Text. View Object in the diagram is the abstract class which is given responsibilities by two decorator objects • a. Border. Decorator draws a border around the Text. View object • a. Scroll. Decorator gives the Text. View object functional scroll bars

Example: Text. View Object • The class diagram shows that the Scroll. Decorator and Border. Decorator 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 “Visual. Component”

Sample Code: Decorator • Subclass of Visual. Component called “Decorator” • Decorator subclass is able to reference Visual. Component through the _component variable

Sample Code: Decorator • Passing functions • Requests are passed to _component

Sample Code: Decorator • Subclass of the Decorator class, “Border. Decorator” • Specifies individual operations, draws the border on the Visual. Component • Inherits all operation implementations from Decorator

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/Java. Resources/Design. Patterns/D ecorator. Pattern. htm

Any Questions?