180 likes | 342 Vues
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.
E N D
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. 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