Adapter Pattern

Description

Adapter is the structural pattern for making an existing class fit the interface your code expects - like a travel plug between your laptop and a foreign socket. It's how real systems integrate vendor SDKs, legacy modules and third-party libraries without letting their quirks spread through the codebase. This skill covers the pattern, how to apply it, and what an adapter must translate besides method names.

Your code has settled on how it wants to pay for things - but the billing library you have to use speaks a different language: other method names, amounts in cents instead of dollars, numeric status codes instead of exceptions.

The tempting fix is to convert inline, wherever you need it:

class CheckoutService {
    void pay(double dollars) {
        new LegacyBillingClient().charge((int) Math.round(dollars * 100)); // dollars -> cents, here...
    }
}
class RefundService {
    void refund(double dollars) {
        new LegacyBillingClient().credit((int) Math.round(dollars * 100)); // ...and copy-pasted here
    }
}

class CheckoutService:
    def pay(self, dollars: float) -> None:
        LegacyBillingClient().charge(round(dollars * 100))   # dollars -> cents, here...


class RefundService:
    def refund(self, dollars: float) -> None:
        LegacyBillingClient().credit(round(dollars * 100))   # ...and copy-pasted here

Every quirk of the library is now scattered across your codebase. When the library changes (or you switch vendors), you have to hunt down every call site.

We'll go from simple to more technical:

1. The pattern: target, adaptee and adapter.
2. Writing an adapter, step by step.
3. Where you'll see adapters in the standard libraries and in integrations.
4. What adapters must translate - units, results and errors - and choosing among the structural patterns.

The pattern

An Adapter is a small class that implements the interface your code wants and translates each call into the interface the library actually has.

• Target - the interface your code depends on (PaymentProcessor).
• Adaptee - the existing class with the "wrong" interface (LegacyBillingClient). You don't change it.
• Adapter - implements the target and holds a reference to the adaptee.

interface PaymentProcessor {
    void pay(double dollars);
    void refund(double dollars);
}

class LegacyBillingAdapter implements PaymentProcessor {
    private final LegacyBillingClient client;

    LegacyBillingAdapter(LegacyBillingClient client) { this.client = client; }

    public void pay(double dollars)    { client.charge(toCents(dollars)); }
    public void refund(double dollars) { client.credit(toCents(dollars)); }

    private int toCents(double dollars) { return (int) Math.round(dollars * 100); }
}

from abc import ABC, abstractmethod


class PaymentProcessor(ABC):
    @abstractmethod
    def pay(self, dollars: float) -> None: ...

    @abstractmethod
    def refund(self, dollars: float) -> None: ...


class LegacyBillingAdapter(PaymentProcessor):
    def __init__(self, client: LegacyBillingClient):
        self._client = client

    def pay(self, dollars: float) -> None:
        self._client.charge(self._to_cents(dollars))

    def refund(self, dollars: float) -> None:
        self._client.credit(self._to_cents(dollars))

    @staticmethod
    def _to_cents(dollars: float) -> int:
        return round(dollars * 100)

Now CheckoutService and RefundService just use a PaymentProcessor. The unit conversion lives in exactly one place.

How it works, step by step

1. Describe what you need in your own terms: the target interface.
2. Write an adapter class that implements that interface.
3. Give the adapter the adaptee through its constructor (composition).
4. In each method, translate: names, parameter order, units, return values and errors.
5. Everything else in your code depends only on the target interface.

Where you'll see it

• InputStreamReader adapts a byte InputStream into a character Reader.
• Arrays.asList(array) lets an array be used wherever a List is expected.
• In Python, io.TextIOWrapper adapts a binary stream into a text stream - InputStreamReader's twin.
• Payment, email and SMS integrations are usually hidden behind your own PaymentGateway / EmailSender interface, with one adapter per vendor - switching vendors becomes a one-class change.

Choosing among the structural patterns

Common mistakes

Check yourself

Try to answer before opening each one - recalling beats re-reading.

1. Besides method names, what does an adapter have to translate?

2. Why is an object adapter (the adaptee in a field) usually preferred to a class adapter (extending the adaptee) in Java?

3. The awkward interface belongs to your own team. Should you write an adapter for it?

Key takeaways

• An adapter makes an existing class fit the interface your code expects - neither side has to change.
• Translate everything at the boundary: names, units, return values and errors.
• Never let vendor types (exceptions, DTOs) leak through your interface.
• Prefer composition (an object adapter) over inheritance.
• If you own the "wrong" interface, fix it rather than adapting around it.