Adapter Design Principle

Today, I want to share some of my knowledge on the Adapter design pattern with everyone as part of my learning.

The Adapter design pattern is an important section of the structural design pattern since this combines the capabilities of two independent incompatible interfaces in a single system.

In our homes, when we have a device having normal plug (type C plug) but don't have a power socket and we are unable to use the device with that power plug, then we try to find a workaround such as finding a power adapter which takes type C plugs as intake and use a power plug as the power source which basically converts the power plug to normal plug mechanically. Similar examples could be our mobile adapters, power adapter, memory card reader, etc.

In all these examples, there is one thing in common, all of these devices are making one interface compatible to another which is a perfect definition of an adapter.

Let's make our problem more complex. What if we want to use two different devices (an A.C. and a table fan) to a same power plug. A normal air conditioner requires a power plug but a table fan requires a normal type C plug. So, here in this case our adapter should have capability to accept requests from multiple type of interfaces and fulfilling their needs from a single power source (considering the wall socket power source is capable of providing energy to above mentioned devices).

So, based on the above problems we all faced in our daily life, we face similar problems in our system when we have to create our system from multiple incompatible interfaces and to tackle such problems, we can adopt adapter design pattern in our system design.

Advantages of using Adapter Design Pattern?

1. This design pattern allow us to use 3rd party vendor services more seamlessly without changing our legacy interface.
2. This design principle gives loose coupling between two interfaces. The change in either the client or the adaptee means change to the adapter only.
3. It is enforced with Single Responsibility Principle (SRP), one of the most important feature of SOLID design principles.

Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

Here is my code snippet explaining the same.

public class Volt {

    private int volts;

    public Volt(int v) {
        this.volts = v;
    }

    public int getVolts() {
        return volts;
    }

    public void setVolts(int volts) {
        this.volts = volts;
    }
}        

public class Socket {

    public Volt getVolt() {
        return new Volt(120);
    }

}        

public interface SocketAdapterService {

    public Volt get120Volt();

    public Volt get12Volt();

    public Volt get3Volt();
}        

public class SocketAdapterServiceImpl implements SocketAdapterService { 

    private final Socket sock = new Socket();

    @Override
    public Volt get120Volt() {
        return sock.getVolt();
    }

    @Override
    public Volt get12Volt() {
        Volt v = sock.getVolt();
        return convertVolt(v, 10);
    }

    @Override
    public Volt get3Volt() {
        Volt v = sock.getVolt();
        return convertVolt(v, 40);
    }

    private Volt convertVolt(Volt v, int i) {
        return new Volt(v.getVolts() / i);
    }
}        

public class AdapterPatternTest {

    public static void main(String[] args) {
        testAdapter();
    }

    private static void testAdapter() {
        Volt v3 = getVolt(3);
        Volt v12 = getVolt(12);
        Volt v120 = getVolt(120);
        System.out.println("v3 volts using Object Adapter=" + v3.getVolts());
        System.out.println("v12 volts using Object Adapter=" + v12.getVolts());
        System.out.println("v120 volts using Object Adapter=" + v120.getVolts());
    }

    private static Volt getVolt(int i) {
        SocketAdapterService socketAdapterService = new SocketAdapterServiceImpl();

        switch (i) {
            case 3 -> {
                return socketAdapterService.get3Volt();
            }
            case 12 -> {
                return socketAdapterService.get12Volt();
            }
            case 120 -> {
                return socketAdapterService.get120Volt();
            }
            default -> {
                System.out.println("Adapter does not support this voltage");
                return null;
            }
        }
    }

}        

You can find the complete code here.

When to use Adapter design pattern?

1. We can use it when we think we have to make connection between two incompatible systems. Both systems may have different code languagess or syntax.
2. We can use it when we require one-to-one, many-to-one or one-to-many conversions in our product.

I took this topic because I recently worked on the Adapter Design Principle here at Awign . Here in Awign, we created a Payment Adapter service following the Adapter Design Principle where our payment service is connected with Cashfree's payment gateway to execute our payouts on required basis. Right now, this is just a one-to-one connection (Awign payment service to Cashfree payment gateway) but going forward to reduce the dependency on a single payment gateway, we might plan to collaborate with more gateways like ICCI, Kotak, Razorpay, etc.

Thanks for reading this till the end. That's all from my side on Adapter Design Principle. You can also find more articles on same on internet with detailed explanation.