Adapter: The Interface Translator
Make incompatible interfaces work together — wrap an old or external class behind the interface your system expects without modifying either side.
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.
Adapter as an architectural boundary
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.
💡Key takeaway
Use Adapter when integrating third-party or legacy code without modifying it — the adapter is the single place that knows about both interfaces, so a vendor change means rewriting one class, not twenty.
🔧 Some exercises may still have errors. If something seems wrong, use the Feedback button (bottom-right of the page) to report it — it helps us fix it fast.
Hint: Use Adapter when you need to integrate third-party or legacy code without modifying it. The adapter is the only place that knows about both interfaces.
✗ Your version