Adapter Pattern

Wrap a class whose interface does not fit so that the code you already have can call it without changing either side.

Overview

The problem it solves The code you already have calls one interface, and a class you need offers a different one. You cannot change the class (it is a library, a vendor SDK or old code with many callers), and you do not want to rewrite every caller. An adapter sits between them. It implements the interface your code expects and translates each call into the calls the other class understands.

The pattern is one of the seven structural patterns in the Gang of Four book (Gamma, Helm, Johnson and Vlissides, *Design Patterns*, 1994). The book calls the interface your code wants the Target, the class you are stuck with the Adaptee, and the translator the Adapter.

Three things change inside the adapter and nowhere else: method names, the shape of arguments and results, and small protocol differences such as units, error codes or exceptions. Business rules do not belong there. If the adapter starts deciding things, it has become something else.

Object adapter and class adapter The book describes two ways to build the adapter. An object adapter holds a reference to the adaptee and delegates to it. A class adapter inherits from both the target and the adaptee at once, which needs multiple inheritance.

  • How it reaches the adaptee — Holds an instance (composition) — Inherits from it
  • Works with subclasses of the adaptee — Yes, any instance you pass in — No, it is bound to one class
  • Can override adaptee behavior — Only by wrapping calls — Yes, by overriding methods
  • Languages — All — Needs multiple inheritance (C++, Python)
  • Interview default — Use this one — Mention it, rarely write it

Python allows multiple inheritance and resolves methods left to right through the method resolution order, so a class adapter is possible there. In Java, a class can extend only one class, so the object form is the only option when the target is a class rather than an interface. Either way, prefer the object adapter: it keeps the adaptee replaceable and the adapter small.

A runnable example Your checkout code talks to a PaymentGateway that takes a decimal amount and an ISO currency code and returns True or False. The vendor SDK you must use wants integer cents, a numeric currency code, and reports success with a status string. The adapter does the three translations and nothing more.

The checkout function never imports the SDK. Swapping vendors means writing one new adapter class; the checkout code and its tests stay as they are.

Adapters you already use | Library | What is adapted | What the client sees | |---|---|---| | Java Arrays.asList(T...) | An array | A fixed-size List backed by that array | | Java InputStreamReader | A byte stream (InputStream) | A character stream (Reader) that decodes bytes with a charset | | A ports-and-adapters codebase | A database driver, a message broker, an HTTP framework | The application's own port interface |

The Java docs describe InputStreamReader as a bridge from byte streams to character streams. In Gang of Four vocabulary it is an adapter: one existing interface reshaped into another. The word bridge in the Javadoc is everyday English, not the Bridge pattern, which separates two hierarchies that both keep growing.

The ports-and-adapters row is Alistair Cockburn's Hexagonal Architecture (2005). The application defines ports, which are the interfaces it needs, and each outside technology gets an adapter that converts between the port and the technology. It is the Adapter pattern used as the rule for every boundary of a system.

Adapter next to its look-alikes Adapter, Facade, Decorator, Proxy and Bridge all wrap another object. Interviewers ask you to tell them apart by intent, not by shape.

  • Adapter — Yes, to one the client already expects — One object — Make an existing class fit
  • Facade — Yes, to a new simpler one — A whole subsystem — Make a subsystem easy to use
  • Decorator — No — One object, often stacked — Add behavior
  • Proxy — No — One object — Control access
  • Bridge — No existing interface to change; both sides are designed together up front — Two hierarchies — Let both sides vary

What you will be able to do - Name Target, Adaptee, Adapter and Client on a class diagram and say which one the client depends on. - Write an object adapter in a few lines and explain why you did not use a class adapter. - Spot an adapter in a codebase: a class that only renames, reshapes and re-types calls. - Keep business rules out of adapters and say where they belong instead. - Tell Adapter from Facade, Decorator, Proxy and Bridge by intent in one sentence each.

Interview questions

  • What are the participants of the Adapter pattern, and who depends on whom?
  • Show the smell an adapter removes, and the fix.
  • When is an adapter the wrong choice?
  • How do you test an adapter?
  • What is a two-way adapter, and when would you need one?

Sign up free to read the full topic

More Low-Level Design topics

Start free on Cariara · Coding problems · System design studio