Adapter Pattern

Anyone who wants to charge a German laptop in England needs an intermediary piece for the socket. The laptop stays as it is, the socket stays as it is too. Only in between sits a small part that translates one form into the other. This exact principle also exists in computer programs, and there it’s called the Adapter Pattern. A program consists of many building blocks that call each other and pass on data. If two building blocks don’t fit together, a third, small piece of program code is written in between that translates. The word Pattern simply means a template: a solution that has worked so well so often that it got a name.

Why you don’t simply rewrite foreign code

Hardly any program is built completely from scratch. Developers use ready-made building blocks from other companies or from freely available collections. These building blocks cannot be changed because they don’t belong to you or because all your own changes would disappear again with the next update. Nevertheless, they have to communicate with your own program.

The adapter solves this problem without touching either side. It sits on the outside and leaves both parts unchanged. This has a practical side effect: if you later want to replace the foreign building block, you only have to rewrite the adapter. The rest of the program doesn’t notice the change at all, because it continues to talk to the adapter and not directly to the foreign part.

This is especially visible in AI applications. A company builds a chatbot and initially uses a provider’s language model for it. A year later, a different model is cheaper or better. Whoever placed an adapter between their program and the provider from the start can switch within a few days. Whoever scattered the provider’s commands throughout the program needs months.

The intermediary piece viewed from inside

Three parties are involved in the Adapter Pattern. First, the part of the program that wants something done. Second, the foreign building block that could do it, but is operated differently than expected. Third, the adapter, which takes on the expectation of the one and reshapes it into the operation of the other.

An example with weather data makes this tangible. The own program wants a temperature in degrees Celsius, as a single number. But the purchased weather service delivers an entire data package with Fahrenheit, air pressure, and place name. The adapter queries the weather service, fetches the package, picks out the Fahrenheit number, converts it to Celsius, and passes on only this one number. To the own program, the adapter looks like a simple temperature sensor.

What matters is what an adapter does not do: it does not invent new capabilities. It only translates. This boundary is often confused. A common misconception is also to equate the adapter with the term interface. An interface is the description of how to operate a building block. The adapter is the component that maps two such descriptions onto each other.

From the charging cable to the banking system

In everyday life, you encounter this principle everywhere that devices from different manufacturers work together. A USB-C-to-headphone-jack piece on a phone is an adapter in the literal sense. In software, the same idea is invisibly embedded in almost every app that displays maps, processes payments, or sends messages.

In the financial world, this pattern is especially widespread. Banks partly operate core systems that are decades old and cannot be replaced. For a modern phone app to access them, layers of adapters lie in between. Experts then speak of legacy systems, meaning old systems that continue to be operated for cost reasons.

In tech news, the term mostly comes up in connection with dependency on individual providers. If a report warns of lock-in, meaning being chained to a cloud or AI provider, the recommended countermeasure is almost always: build in an adapter layer. Caution, risk of confusion: in AI research, small additional modules for cost-efficient fine-tuning of models are also called adapters. This is a different concept with the same name.