The adapter pattern is a design pattern that wraps one piece of code in a thin layer so it fits where it otherwise wouldn’t. The two sides expect different shapes, and rather than change either one, you put a small translator between them. To the rest of the system, the wrapped thing now looks exactly like what it expected.
A travel plug adapter is the everyday version of this. Your laptop charger has UK pins, the hotel wall in Spain has European sockets, and neither one is going to change for you. The adapter sits in between and makes the two fit, without rewiring anything. In code it does the same job: it takes a payment provider, an old reporting tool, or a new shipping service and presents it through the interface the rest of your software already speaks to.
Because it leans on a stable surface and hides the conversion underneath, the adapter is a clean example of abstraction at work. Swap the provider later and you only touch the adapter, not the dozens of places that call it. Say a client is on Mollie for payments and decides to add Stripe for international cards. Without an adapter, every checkout screen would need to know which provider it was talking to. With one, both providers get wrapped to look identical, and the checkout code stays exactly the same. The same trick works when an old in-house system speaks XML and the rest of the app expects JSON. The adapter quietly translates between the two, and neither side has to learn the other’s language.
At TopDevs we reach for the adapter pattern whenever a client needs to connect an external service or a legacy system, so the integration stays contained in one place instead of leaking through the whole codebase.
