Design Pattern articles in this series are listed below:

Design Patterns - An Overview
Design Patterns – Using the Strategy Pattern in C#
Design Patterns – Using the Singleton Pattern in C#
Design Patterns – Using the Adapter Pattern in C#
Design Patterns - Using the Facade Pattern in C#
Design Patterns - Using the Composite Pattern in C#
Design Patterns - Using the Decorator Pattern in C#
Design Patterns - Using the Abstract Factory Pattern in C#
Design Patterns – Using the Builder Pattern in C#
Design Patterns - Using the Observer Pattern in C# (Events and Delegates)
Design Patterns – Using the Chain of Responsibility Pattern in C#
Design Patterns – Using the State Pattern in C#
Design Patterns – Which to use When? Take the Quiz!

What is an Adapter Pattern?

An Adapter pattern also known as the “Wrapper pattern” makes it easier to implement solutions that interface with multiple systems. There are situations in which a system we are working needs to interact with another system, third party API or a legacy component. This interaction becomes challenging if the systems are not compatible with each other. There is no standard way to implement a particular system. How do we make it easy to tie all the incompatible systems together? With the help of the Adapter pattern.

The Adapter pattern has been implemented in the .NET framework that makes it easy for developers to use legacy COM objects from managed code. Check out the MSDN link for more information.

In the real world, we always use an adapter to link two systems that are incompatible. For example, most of us have used a PS2 to USB adapter to make incompatible ports compatible.

Illustration - A real world example of an adapter

How’s it implemented?

Let’s imagine we are working on an e-commerce application that connects to a payment gateway that charges customers for any products they purchase. We are now working on a very simple module of this e-commerce application that requires us to get a list of customers that have been charged in a comma separated format. When we look at the payment gateway’s API, we find out that the there is no way to get a list in the format we need. We decide to hook these two systems together using the Adapter pattern.

The Adapter pattern has the following components:

1. Adaptee – The class that contains the functionality that the client is interested in. However, it’s not compatible with the client

2. Target– This is the domain specific interface the client uses

3. Adapter – This class adapts the Target to the Adaptee class

4. Client – The client that is expected to interact with the incompatible Adaptee class

Let’s take a look at one class at a time and map it to the components listed above

public class MoolahGateway
{
    public List<string> GetCustomers()
    {
        List<string> listCustomers = new List<string>();

        listCustomers.Add("Bob Smith");
        listCustomers.Add("Chris Thomas");
        listCustomers.Add("Dave Mathews");

        return listCustomers;
    }
}

The MoolahGateway class is the API that we need to work with. This is the Adaptee class. It has a method that returns the list of customers as a generic list (in the format that is not compatible to our requirements). Note that this is a very simple version of the implementation. In real world, this list would be extracted from the datasource. But for this article, it lets us focus on the concept of the Adapter pattern.

public interface IGateway
{
   string GetCSVCustomers();
}

The IGateway is an interface that represents the Target component explained earlier.

public class MoolahGatewayAdapter : IGateway
{
    private MoolahGateway _moolahGateway = new MoolahGateway();

    string IGateway.GetCSVCustomers()
    {
        List<string> listCustomers = _moolahGateway.GetCustomers();
        StringBuilder csvCustomers = new StringBuilder();

        foreach (var item in listCustomers)
        {
            csvCustomers.Append(item);
            csvCustomers.Append(",");
        }

        return csvCustomers.ToString().TrimEnd(',');
    }
}

The MoolahGatewayAdapter class is the implementation of the Adapter. This is the class that the client will be interacting with. It does the grunt work of resolving the incompatibility issue and acts as a bridge between the Adaptee and the client.

class Program
{
    static void Main(string[] args)
    {
        IGateway gateway = new MoolahGatewayAdapter();

        Console.WriteLine(gateway.GetCSVCustomers());
    }
}

Finally, the Client that prints the list of customers in the CSV format. The output is as shown below.

Let’s extend this example and consider another gateway that the e-commerce application uses. This gateway has API that retrieves the list of customers as a an array of Customers. We can easily link this new gateway by creating a new Adapter class that implements the IGateway interface. The new Adapter class would have a method that iterates through the array and builds the CSV list. The client can make a choice between the two adapters and call the GetCSVCustomers() method without being aware of the method’s implementation.

Physical Model – Class Diagram

Conclusion

The Adapter pattern is the chosen pattern to connect incompatible systems. It does not matter if the systems do not have the same interface. A common interface can be easily built and multiple systems can be “linked” this way. If you like reading these articles and don’t want to miss any, you can subscribe to the RSS feed or follow me on Twitter. Stay tuned for more interesting articles soon.