Adapter Pattern

Adapter pattern enables application to use classes or interfaces which are not matching its requirement. Adapter pattern falls under structural pattern of GOF (Gang of Four) pattern.

When to use –

Adapter pattern can be used when you want to utilize third party API which is not compatible or mismatching your current implementation. You want to use third party API in your application but your application doesn’t understand the object of third party API in such scenarios, you need to use Adapter pattern to create wrapper class which contains code to utilize third party API. You can also consider to use adapter pattern when you have an existing system and you want to use some features of new application but interfaces are different.

There are so many real world example of adapter pattern but most common is power adapter. India’s power socket and plug is different from America’s power socket and plug. To use any Indian electronic appliances in America, you need an adapter (universal power adapter) which allows India’s plug to fit in America’s power socket. In .net world SQLAdapter, OracleAdapter are good example of adapter pattern.

Major components of Adapter pattern –

• ITarget – This is an interface which client wants to use to achieve its functionality.
• Adapter – This class implement ITarget interface and responsible for providing functionality that client wants and communicates with Adaptee class.
• Adaptee – This class has actual functionality that client wants but its interface is not compatible with client.
• Client – This class want to achieve functionality that Adaptee class has but via ITarget interface due to incompatible interfaces.

Let’s have a look on below code demonstrating adapter pattern.

Code –

public enum TransactionType

{

    Cash,

    NetBanking,

    CreditCard

}

//ITarget - Target interface

public interface IPayment

{

    void PayAmount(TransactionType type, double amount);

}

//Adapter class - integrates with Adaptee

public class PaymentGatewayAdapter : IPayment

{

    public void PayAmount(TransactionType type, double amount)

    {

        PayPalPaymentGateway payPalGateway = new PayPalPaymentGateway();

        switch (type)

        {

            case TransactionType.Cash:

                payPalGateway.PayCash(amount);

                break;

            case TransactionType.NetBanking:

                payPalGateway.PayViaNetBanking(amount);

                break;

            case TransactionType.CreditCard:

                payPalGateway.PayViaCard(amount);

                break;

            default:

                break;

        }

    }

}

//Adaptee – Third party API

public class PayPalPaymentGateway

{

    public void PayCash(double amount)

    {

        Console.WriteLine("Cash payment successful for amount {0}", amount);

    }

    public void PayViaCard(double amount)

    {

        Console.WriteLine("Card payment successful for amount {0}", amount);

    }

    public void PayViaNetBanking(double amount)

    {

        Console.WriteLine("Net Banking payment successful for amount {0}", amount);

    }

}

//Client

class Program

{

    static void Main(string[] args)

    {

        IPayment paymentGateway = new PaymentGatewayAdapter();

        paymentGateway.PayAmount(TransactionType.NetBanking, 2000);

        Console.ReadLine();

    }

}

Output –

As you can see in above example, PaypalPaymentGateway class is third party API which can directly be used by client to make payments but application has some different implementation and client doesn't want to change it and which is not matching with Third party API. In above example, third party API has different methods for different types of payments. PaymentGatewayAdapter class has adopted third party API differences and returned functionality that client wanted. This example is very simple but actual implementation of Adapter class may be more complex than this based on third party API object and client requirement.

In above example, if PayPal payment gateway renames its ‘PayCash’ method or any other method then client doesn’t need to change anything only change in Adapter class. Similarly, if you decide to use some other payment gateway instead of PayPal you don’t need to change client side implementation just change in Adapter class to integrate with new payment gateway interface.

I hope this article helps you to understand more about Adapter Pattern. Please leave your feedback in comments below.

References –

MSDN

DoFactory

See Also –

Creational Patterns	Structural Patterns	Behavioral Patterns
Singleton Pattern	Adapter Pattern	Chain of Responsibility Pattern
Thread safe singleton pattern	Bridge Pattern	Command Pattern
Factory Pattern	Composite Pattern	Interpreter Pattern
Abstract Factory Pattern	Decorator Pattern	Iterator Pattern
Builder Pattern	Facade Pattern	Mediator Pattern
Prototype Pattern	Flyweight Pattern	Memento Pattern
	Proxy Pattern	Observer Pattern
		State Pattern
		Strategy Pattern
		Template Method Pattern
		Visitor Pattern