Decorator Pattern

Decorator Pattern

In short the Decorator Pattern allows responsibilities to be assigned to an object without sub-classing and add the responsibilities dynamically to the object. Decorators provide a flexible alternative to sub-classing for extending functionality.

Decorator Pattern addresses the limitation of inheritance. Inheritance adds behaviour to an object at compile time where decorator provides a new behaviour to an object at runtime.

Inheritance can be used where the sub classes can be predicted while with the decorator such predictability is not required.

The main advantage of the Decorator pattern is that it avoids extensive sub-classing.

Other advantages of using the Decorator Pattern include:

The ability to develop more elegant programmes as too many sub-classing are removed. This further makes it easy to maintain the application.

The Decorator also provides the capability to add new functions to an object without affecting other objects. All other objects remain intact during developing or during maintenance of the application.

Decorator Pattern makes it possible to easily add or remove responsibility from an object dynamically.

Decorators can be recursively nested without any other objects being able to tell the difference, allowing a near infinite amount of customization.

Make ones code more flexible. Decorating is more flexible than plain, old static inheritance. With the decorator pattern, one can add, any number of decorators to a particular component.

The Decorator pattern keeps things simple. When using the decorator pattern, one does not have to complex classes that consider every possible scenario. With the Decorator Pattern, one only needs to design a simple abstract class and then decorate the class as necessary. One can further develop new concrete decorators without disturbing the original design of the application.


Demerits of the Decorator pattern

Identity crisis problem: Decorators wrap themselves around components. They therefore change the identity of the component onto which they wrap themselves. The resulting component is not therefore the same as the original component. One therefore needs to be careful about object identity whenever reference is made to one of the decorated components.


The other problem is Object Critters.
Even with the decorator pattern, one can still have too many classes, especially concrete decorator classes. This is the same problem the inheritance has.[1]


In this section the differences between Decorator Pattern and other patterns namely: Adapter, Proxy, Composite, and Strategy is examined


Decorator Vs Adapter

The Adapter Pattern provides a different interface to the object it adapts, whereas decorator changes the object’s responsibilities or simply provides an enhanced interface to the subject.

When compared to Adaptor Pattern, the Decorator Pattern is more transparent to the client. The other difference between the Adapter and Decorator Pattern is that the Decorator Pattern support recursive composition, which is not possible with pure Adapter Pattern.

Decorator Vs Proxy Pattern

Proxy Pattern and Decorator Pattern have different purposes but similar structures. The main similarity between the two is that they both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward the request.

Proxy pattern however, controls access to the object whereas a decorator adds additional responsibilities to an object.

Decorator Vs Façade Pattern

Façade pattern provides a way of hiding a complex class, whereas decorator adds function by wrapping a class.

Decorator Vs Composite pattern

Composite and Decorate when examined closely have similar structure diagrams, which re-enforces the fact that both rely on recursive composition to organize an open ended number of objects. Further examination of the Decorator and Composite Patterns shows that decorators can be viewed as a delegate Composite with only one component.

The Composite Pattern’s focus is not on embellishment but on representation. This makes the intent of both patterns complementary. [2]




[1]

Barry Burd and Micheal P Redlich
Decorator Pattern
(2007)
http://javaboutique.internet.com/tutorials/decorator/index-4.html
Accessed: 22nd March 2007

[2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Design Patterns,
Elements of Reusable Object-Oriented Software,
1995
Addison-Wesley
Pages 219 -220