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

Adapter Pattern

Introduction

This particular pattern seems to very interesting and goes with the core concept of java. I really liked the concept.

In today’s lesson we have discussed about how a pattern is preserved in a catalogue generally. I was curious to find out if all this preserving elements were all necessary to describe the nature of a pattern. So I picked one of the GOF pattern which adapter. I am trying to determine the importance and applicability of these elements in adapter.

Adapter Pattern

Adapters are used to enable objects with different interfaces to communicate with each other.
Adapters come in two flavors, object adapters and class adapters. These two methods embody the difference between the use of inheritance and composition to solve problems.

This pattern is used when;

·User wants to use existing class but the interface doesn't match user needs
·Creating a class that communicates with unrelated classes

There are two types of this pattern; Object Adapter pattern and Class Adapter pattern

Object Adapter Pattern

In this pattern the adapter holds the instance of the class it wraps and makes call to the instance of the wrapped object. [1]

Class Adapter Pattern

The class adapter pattern uses the concept of multiple inheritance. The adapter is created inheriting interfaces from both the interface that is expected and the interface that is pre-existing. [1]

Adapter Pattern Template [2]

Intent
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

Also Known As
Wrapper

Motivation
Sometimes a toolkit or class library can not be used because its interface is incompatible with the interface required by an application

We can not change the library interface, since we may not have its source code. Even if we did have the source code, we probably should not change the library for each domain-specific application

Structure
A class adapter uses multiple inheritances to adapt one interface to another:
An object adapter relies on object composition:

Applicability
Use the Adapter pattern when You want to use an existing class, and its interface does not match the one you need. You want to create a reusable class that cooperates with unrelated classes with incompatible interfaces

Implementation Issues
How much adapting should be done?
Simple interface conversion that just changes operation names and order of arguments

Totally different set of operations
Does the adapter provide two-way transparency?

A two-way adapter supports both the Target and the Adaptee interface. It allows an adapted object (Adapter) to appear as an Adaptee object or a Target

Adapter Pattern Example

public class ButtonDemo {
public ButtonDemo() {
Button button = new Button("Press me");
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
doOperation();
}
});
}
public void doOperation() { whatever }
}

Button objects expect to be able to invoke the actionPerformed() method on their associated ActionListener objects. But the ButtonDemo class does not have this method! It really wants the button to invoke its doOperation() method. The anonymous inner class we instantiated acts as an adapter object, adapting ButtonDemo to ActionListener!

Conclusion

Class adapters are a lot flexible than object adapters in that they involve fewer classes and are useful if total decoupling of the client and adaptee is not needed.

References:

1.http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/adapter.htm

2.Design Patterns: Elements of Reusable Object-Oriented Software By Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides