← Back to PatternPip

ADAPTER / THE IDEA IN A MINUTE

Different languages.
One conversation.

Adapter lets an existing object work with a client that expects a different interface.

Wrap the object with a small translator. The client uses its familiar contract. The adapter translates calls for the existing service and responses for the client.

What does not fit?
An existing service has a different interface or data format.
What stays stable?
The interface the client already expects.
Where does translation go?
In an adapter that wraps the incompatible service.

FOLLOW THE RESPONSE

Different format. Same display.

Try it yourself

These local sample services describe the same weather in different ways. Request a reading and follow the data returning to the app.

THE PROVIDER

Legacy Forecast

getForecast()
{
  "temp_f": 64.4,
  "sky_code": 1
}

Sample response · vendor format

THE ADAPTER

FahrenheitAdapter

getForecast() → read()

(°F − 32) × 5 / 9 → °C

sky_code → condition

Wrap the existing feed. Translate at the boundary.

THE APP’S DISPLAY

Weather panel

source.read()

—

Waiting for a reading

Expects Celsius + sunny / rainy.
Display rounds to one decimal.

What if the provider sends a code we don’t understand?

Request again. An adapter cannot safely guess whether an unknown code means sun or rain.

Request weather to follow the response from provider to display.

Try this: read the Fahrenheit feed, then switch to Celsius Station. Compare the raw response with the display’s result.

Reduced motion is on; results appear immediately. The caller still chooses the provider. The adapter owns the translation.

Useful when interfaces do not fit.

Connect an existing library, vendor service or legacy system without teaching every client its conventions.

Start with the smallest useful boundary.

A mapping function may be enough for one conversion. An adapter adds a wrapper to maintain, and cannot make missing data or incompatible behavior disappear.

Choose your next step.