Adapter: The Interface Translator

Why this matters

Real-world analogy: a power plug adapter lets your European charger work in a US socket without modifying either. In code you often inherit a legacy payment gateway or a third-party SDK with its own quirky method signatures. You cannot change that code, and you should not litter your entire codebase with calls that know about its internal API. The Adapter wraps the incompatible class behind the interface your system already understands.

Analogía real: un adaptador de enchufe permite que tu cargador europeo funcione en un tomacorriente de EE.UU. sin modificar ninguno de los dos. En código a menudo heredas una pasarela de pago legacy o un SDK de terceros con sus propias firmas de método peculiares. No puedes cambiar ese código, y no debes contaminar toda tu base de código con llamadas que conocen su API interna. El Adapter envuelve la clase incompatible detrás de la interfaz que tu sistema ya entiende.

✗ The problem

✓ The solution

Adapter as an architectural boundaryAdapter como frontera arquitectónica

The Adapter is the only class allowed to know about both the legacy interface and your modern one. This is the Dependency Inversion Principle in action: your business logic depends on an abstraction (PaymentProcessor), and the adapter is a low-level detail that points inward. Replacing the legacy gateway later means writing a new adapter — nothing else changes.

El Adapter es la única clase que tiene permitido conocer tanto la interfaz legacy como la moderna. Esto es el Principio de Inversión de Dependencias en acción: tu lógica de negocio depende de una abstracción (PaymentProcessor), y el adaptador es un detalle de bajo nivel que apunta hacia adentro. Reemplazar la pasarela legacy luego significa escribir un nuevo adaptador — nada más cambia.