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

Abstract Factory Design Pattern

Abstract!

“Abstract” sounds pretty technical but what exactly it means in English which might help to clarify the functions and meaning of abstract in design pattern. Well, I thought I might as well find out the synonyms of abstract and try to relate it to the design pattern. Below is the result, this is what I have found from answers.com

“Considered apart from concrete existence”

“Not applied or practical; theoretical”

These two lines of sentence did give me a bigger picture of abstract factory pattern. So let’s define it formally

Abstract Factory Design Pattern

I have been looking for some formal definition of abstract factory pattern and gather the following definition below
“An abstract factory class defines methods to create an instance of each abstract class that represents a user interface widget. Concrete factories are concrete subclasses of an abstract factory that implements its methods to create instances of concrete widget classes for the same platform.” [1]

The definition sounds a bit technical but what I think about this pattern is it lets you take concern of the bigger picture and worry about the facts later. The main intent of this pattern is to 'provide an interface for creating families of related or dependent objects without specifying their concrete classes' [2].

Analogy

A fine analogy for this is a pasta maker. A pasta maker will make different types of pasta, depending what kind of disk is loaded into the appliance. All disks should have definite properties in general, so that they will work with the pasta maker. This specification for the disks is the Abstract Factory, and each specific disk is a Factory. We will never see an Abstract Factory, because one can never exist, but all Factories (pasta maker disks) inherit their properties from the abstract Factory. In this way, all disks will work in the pasta maker, since they all conform to the same specifications. The pasta maker doesn't care what the disk is doing, nor should it. You turn the handle on the pasta maker, and the disk makes an exact outline of pasta come out. Each individual disk contains the information of how to create the pasta, and the pasta maker does not.

Structure

The Abstract Factory defines a Factory Method per product. Each Factory Method encapsulates the new operator and the concrete, platform-specific, product classes. Each "platform" is then modeled with a Factory derived class.

Finally we can say the intent of this pattern are

1. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

2. hierarchy that encapsulates: many possible "platforms", and the construction of a suite of "products".

3. The new operator considered harmful.

References:

1.http://www.developer.com/java/other/article.php/626001

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