Decorator Pattern

Today we have looked on one of the most popular design pattern “Decorator”. The name sounds interesting my initial understanding of this pattern were it helps us to decorate classes and subclasses in a typical OOP programming environment.

But below is what I have learned formally through out today’s lecture.

The Decorator Pattern is used for adding additional functionality to a particular object as opposed to a class of objects. It is easy to add functionality to an entire class of objects by subclassing an object, but it is impossible to extend a single object this way. With the Decorator Pattern, we can add functionality to a single object and leave others like it unmodified. [1]

A Decorator, also known as a Wrapper, is an object that has an interface identical to an object that it contains. Any calls that the decorator gets, it relays to the object that it contains, and adds its own functionality along the way, either before or after the call. This gives you a lot of flexibility, since you can change what the decorator does at runtime, as opposed to having the change be static and determined at compile time by subclassing. Since a Decorator complies with the interface that the object that it contains, the Decorator is indistinguishable from the object that it contains. That is, a Decorator is a concrete instance of the abstract class, and thus is indistinguishable from any other concrete instance, including other decorators. This can be used to great advantage, as you can recursively nest decorators without any other objects being able to tell the difference, allowing a near infinite amount of customization.

The Decorator Pattern attaches additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for extending functionality.

Quickly, had a look on the intent of this pattern which can give us initial ideas about this pattern and why it is for?

Intent [2]

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Client-specified embellishment of a core object by recursively wrapping it. Wrapping a gift, putting it in a box, and wrapping the box.

Structure of Decorator

As we can see it from the UML notation of the decorator the client is always interested in CoreFunctionality.doThis(). The client may, or may not, be interested in OptionalOne.doThis() and OptionalTwo.doThis(). Each of these classes always delegate to the Decorator base class, and that class always delegates to the contained "wrappee" object.


Rules of thumb [3]

To explore more I have also gone through GOF’s book and found some interesting comments on this pattern. Below is the list of couple of them

Adapter changes an object's interface, Decorator enhances an object's responsibilities. Decorator is thus more transparent to the client. As a consequence, Decorator supports recursive composition, which isn't possible with pure Adapters. [GoF, p149]

Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface. [GoF, p216]

Decorator lets you change the skin of an object. Strategy lets you change the guts. [GoF, p184]

Composite and Decorator have similar structure diagrams, reflecting the fact that both rely on recursive composition to organize an open-ended number of objects. [GoF, p219]

Conclusion

So far I think decorator is a very important design pattern can be applied in the PAFSD coursework. The amount of work can be perceived by decorator pattern is beyond the imagination. I have tried to learn how decorator pattern has been applied in java and came to know that JAVA I/O is a solid example of decorator pattern in java. Now that I have learnt about decorator pattern my aim would be to implement it in my PAFSD task 2.

References:

1.http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/DecoratorPattern.htm
2.http://www.oreilly.com/catalog/hfdesignpat/chapter/ch03.pdf
3.Design Patterns: Elements of Reusable Object-Oriented Software By Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides