Adapter Pattern falls under Structural pattern:
According to the GoF, the intent of the Adapter pattern is,
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces
Problem:
Sometimes a toolkit or class library can not be used because its interface is incompatible with the interface required by an application and We can not change the library interface, since we may not have its source code. For example the below example uses the grid which have the Method called Fill. But lets say at some point of time you might like to use Infragistics grid(3rd party) which is not having the method called “Fill”, for example, and you may not populate the Client object with the Infragistics grid because of this incompatibility.
Solution:
The solution is to create an InfragisticsAdapter(Who Adapts the adaptee to client – pattern) which composes the Adaptee(Infragistics) and the InfragisticsAdapter will be compatible with the existing interface so that the client can be populated with Adapter.
Please find below the UML for this pattern:
The UML class diagram above describes an implementation of the adapter design pattern. The items in the diagram are described below:
Client: The client class is that which requires the use of an incompatible type. It expects to interact with a type that implements the ITarget interface. However, the class that we wish it to use is the incompatible Adaptee.
ITarget: This is the expected interface for the client class. Although shown in the diagram as an interface, it may be a class that the adapter inherits. If a class is used, the adapter must override its members.
Adaptee: This class contains the functionality that is required by the client. However, its interface is not compatible with that which is expected.
Adapter: This class provides the link between the incompatible Client and Adaptee classes. The adapter implements the ITarget interface and contains a private instance of the Adaptee class. When the client executes MethodA on the ITarget interface, MethodA in the adapter translates this request to a call to MethodB on the internal Adaptee instance.
Example:
public class Client
{
public Client(IGrid iGrid)
{
this.iGrid = iGrid;
}
private IGrid iGrid;
public void PopulateGrid(DataSet ds)
{
iGrid.Fill(ds);
}
}
public interface IGrid
{
void Fill(DataSet ds);
}
public class Infragistics
{
public void DataFill(DataSet ds)
{
// fill the data into grid.
}
}
public class InfragisticsAdapter : IGrid
{
Infragistics _adaptee = new Infragistics();
public void Fill(DataSet ds)
{
_adaptee.DataFill(ds);
}
}
public void static Main()
{
var client = new Client(new InfragisticsAdapter());
var ds = GetDataset();
client.PopulateGrid(ds); //– Hurray it will now work.
}
Rules of thumb
* Adapter makes things work after they’re designed; Bridge makes them work before they are.
* Bridge is designed up-front to let the abstraction and the implementation vary independently. Adapter is retrofitted to make unrelated classes work together.
* Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.
* Adapter is meant to change the interface of an existing object. Decorator enhances another object without changing its interface. Decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports recursive composition, which isn’t possible with pure Adapters.
* Facade defines a new interface, whereas Adapter reuses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one.