Design patterns article 12 — Adapter design pattern

When we wanted to plug in an electronic device have three pin plug, we looked for a switch with three pins. However, the place we were at, there were all two pin switches. Now, we could not really get rid of third pin in our device. So we decided to buy an accessory that would allow us to plug three pin device to two pin switch. That accessory is called ‘Three pin adapter’. How it solved our problem? It was having two pin connector at one end and three pin switch at other end. So we plugged it adapter in the two pin switch and plugged in our device in three pin switch of adapter.

This is real world analogy of adapters. If you observe, there are adapters everywhere. You don’t understand any language and you have to read something, use translator — It is adapter. You don’t have compatible charger for your phone, get any charger, use connector and you can charge your phone — that connector is ‘adapter’. You are travelling in any foreign country, the pin configuration is different, you use adapter.

Adapter example

So what is adapter, you ask? If you have two incompatible interfaces (two pin switch — three pin plug) and you need to share information/perform operation with them combined, you use the middleware — that is ‘adapter’.

In software programming, we can use adapter design pattern when we come across such incompatibilities-

1. The input data format is different and the output data format is different.
2. The existing class provides property value and basic information but client needs more information/configuration.

Consider a requirement where we receive all temperature values in Fahrenheit through web service and we need to pass them as they are to database however we need to show them to user in Celsius. So we already have

1. Interface based on input data and
2. Logic to decode service response.

and inconsistency we are facing in

1. The way we are receiving data (Unit — Fahrenheit) vs
2. The way we would like to show same data to user in different unit (Unit — Celsius).

So let’s see how adapter pattern would help us.

1. You already have interface based on response received from web service

Available interface based on input

2. You already have input class where service response is decoded. This class can be as-is used to store values in database. No adapter is needed.

Input class

3. But we need values in different unit show show on user interface. So lets design class based on same interface. That class will be our adapter.

Adapter class — implements same interface

If you see, we have injected the input class since we need to use those values, apply formula and return result to user interface.

4. The client would use adapter in following way

Client application

For database operation, since no adapter is required, we need not use adapter. For UI, we need adapter implementation.

Conclusion- There are many scenarios where we face inconsistent interfaces e.g. input output data formats. Adapter pattern comes handy to solve such issues. Frankly speaking, subconsciously we always use adapters. We just need to identify them to use them effectively.