Adapter: El Traductor de Interfaces
Hace que interfaces incompatibles trabajen juntas — envuelve una clase antigua o externa detrás de la interfaz que tu sistema espera sin modificar ninguno de los lados.
Por qué importa
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.
Adapter como frontera arquitectónica
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.
💡Conclusión clave
Usa Adapter cuando integras código de terceros o legacy sin modificarlo — el adaptador es el único lugar que conoce ambas interfaces, de modo que un cambio de proveedor significa reescribir una clase, no veinte.
🔧 Algunos ejercicios pueden tener errores. Si algo parece incorrecto, usa el botón Feedback (abajo a la derecha) para reportarlo — nos ayuda a corregirlo rápido.
Pista: Usa Adapter cuando necesitas integrar código de terceros o legado sin modificarlo. El adaptador es el único lugar que conoce ambas interfaces.
✗ Tu versión