Adapter pattern

Avijeet Dash & Satyabrata Dash

Intent

Convert the interface of a class into another interface that clients expect.

In 30 Seconds

Here the catch is "achieving reusability by converting an existing interface to a new interface". Let’s say we have a class ‘’A’’ that has getX() method signatures. But the client code uses get ("X") method signature for calculation. Now how to bridge this interface (function signature) difference?

We need can use an one Adapter class here to wrap the which will convert all
the getX() methods to inside get("X") methods. We can write an adapter
(wrapper) class ‘B’ around ‘A’ to make it act like a hash table (this is
the target interface which will give us get ("X") type of signature).
Adapter (B) adapts the Adaptee (A) interface to the Target’s ( HashTable)
interface. Thus avoids rewriting all the Adaptee (A) code just for the sake of
the new interface.

Motivation

Two styles of implementation of the pattern are possible. We can implement
the pattern in two ways: class adapters and object adapters. Class
adapters are realized by subclassing both target interface and the adaptee
implementation. This is to yield a single object (multiple inheritance). Object
adapters are realized by delegating operations from the adapter object to the
adaptee object by having adaptee object as attributes (object composition).

A class adapter uses inheritance so it can be used to adapt only a class and
all its parents but not subclasses. A Class adapter introduces only one object
and hence, avoids additional pointer indirection (which happens in languages
like c++ where pointers are used for object references). Object adapters on the
other hand use composition to make an Adapter work with many Adaptees. Here
Adapter can’t override Adaptee behavior as it is doesn’t know which Adaptee
it is working with.

Structure

Class Adapter and Object Adapter

Click here https://www.ciol.com/images/adapter.gif
to view the image

Sample Code

/*

EXAMPLE-1

In a Class Adapter pattern, Adapter extends the Adaptee. When the
adapter is used in client code, it works as a Hashtable and gives get
("X") function signature.

The class adapter is supposed to extend the Target as well, but Java doesn’t
support multiple inheritance, which is achieved by using multiple interface
implementation. In this case, we can implement Map interface that Hashtable
implements. But for simplicity we have ignored the implementation of the
interface.

*/

class myAdapter extends Adaptee

{

Hashtable variables = new Hashtable( 20);

public myAdapter()

{

// calling methods of parent class i.e. the Adaptee

variables.put( "AUTH_TYPE" , getAuthType());

variables.put( "REMOTE_USER", getRemoteUser());

//other methods

}

public Object get(Object key)

{

return variables.get( key );

}

//other methods

}

/*

This is an object adapter, where myAdapter is the Adapter, ‘Adaptee’ is
the adaptee and Hashtable is the Target. The Adapter delegates the
responsibilities to an adaptee to get the values.

*/

class myAdapter extends Hashtable

{

Hashtable variables = new Hashtable(20);

// composition of an object

public myAdapter( Adaptee adaptee )

{

variables.put( "AUTH_TYPE" , adaptee.getAuthType());

variables.put( "REMOTE_USER" , adaptee.getRemoteUser());

//other methods

}

public Object get(Object key)

{

return variables.get( key );

}

//other methods

}

/*

EXAMPLE — 2

Here we have adapted one Local class here to make that remotely
available. The local class neither extends UnicastRemoteObject nor its
operations throw RemoteException as required by java RMI specification. So we
have defined an Adapter class that wraps around the Local class and also
conforms to RMI specification to be remotely available.

Java doesn’t support multiple inheritance. But the Remote class must extend
UnicastRemoteObject class. So it is not possible to extend the Adaptee class in
our example. So we have adapted Object Adapter here. But this design conforms to
the basic Design principle of favoring Composition to Inheritance.

*/

//Adaptee Class which is a local class

class CustomerInfo{

private int custId;

private float salary;

public float getSalary(int custId){

/*

Write code here to fetch salary from database

it is hardcoded here to Rs. 1000 for simplicity

*/

salary=1000;

return salary;

}

}

// Declare the Remote Interface

interface IRemoteCustomerInfo extends java.rmi.Remote{

/*

All remote methods throw java.rmi.RemoteException as part of

java RMI requirement.

*/

public float getSalary(int custId) throws java.rmi.RemoteException;

}

// Adapter class that adapts a local class to a remote implementation

public class RemoteCustomerInfoAdapter extends
java.rmi.server.UnicastRemoteObject

implements IRemoteCustomerInfo{

protected CustomerInfo adaptee;

public RemoteCustomerInfoAdapter(CustomerInfo customerInfo)

throws java.rmi.RemoteException{

		this.adaptee=adaptee;

}

public float getSalary(int custId) throws java.rmi.RemoteException{

return adaptee.getSalary(custId);

}

}		

RemoteCustomerInfoAdapter is now ready for use as a Remote class.

Complexities simplified

Pluggable Adapters

In Example-1 we adapted a class with getX() methods to a
Hashtable interface. It is likely that we may adapt another class with getX()
methods to a Hashtable in the future. It would be appropriate to write one class
to do all such adapting. Pluggable adapter Adapter adapts dynamically to one of
the adapters. Adapter decides which class it adapts based on parameters or
differing constructors.

Two-way Adapters

Two-way Adapters are more transparent to the clients than one-way
Adapters as they conform to the interfaces of both Adaptee and Target. So the
client can use both the interfaces with the same Adapter class without knowing
anything about the Adaptee. We can do that in Example-1 by providing both getX()
and get("X") interfaces.

Also Known as and Related Patterns

This pattern is also known as Wrapper.

Bridge has similar structure as an object adapter, but it has a different
intent of separating the interface from the implementation.

Decorator enhances an object’s responsibility dynamically without
changing the interface and hence more transparent than Adapters.

Proxy defines a representation for another object without changing its
interface.