Adapter Pattern: Make Two Interfaces That Weren't Built to Talk, Talk

Your checkout is clean. Every path — pay, refund, reconcile — calls one interface you own: PaymentGateway.charge(Money, customerId). Then a business decision lands: you’re switching payment providers, and the new one ships a JAR.

You open the SDK and it speaks a different language. Amounts are long values in the smallest currency unit, not a BigDecimal. The method is createCharge(long, String, String), not charge. It hands back a StripeCharge object, not your PaymentResult. Nothing lines up — and you can’t rename their methods, because you can’t edit their code. You also refuse to rewrite checkout, refunds, and reconciliation to match a vendor you might swap out next year.

The problem is not that either side is wrong. Both are perfectly reasonable interfaces. The problem is that they were designed in different rooms and now have to meet. The Gang of Four named the seam that lets them.

The intuition: the travel power plug

You fly from London to Mumbai with a laptop charger. The charger is fine. The wall socket is fine. They just don’t fit — the pins are shaped differently. You do not rewire your charger, and you certainly don’t rewire the hotel. You slip a plug adapter between them.

Notice what the adapter does and does not do. It changes the shape of the connection so the pins meet. It does not change the voltage — it doesn’t add behavior, transform the electricity, or make your charger charge faster. That distinction is the whole pattern: an Adapter re-shapes an interface so two parties can connect. It is a translator, not an enhancer.

The members-only continuation builds the three-role structure with live class boxes and a diagram, walks the real adapter code (data, call, and result translation), traces InputStreamReader in the JDK, weighs object vs class adapters, untangles Adapter from Decorator and Facade, and closes with an interview coding challenge and a quiz.