Adapter Pattern Explained

Explanation

The Adapter pattern acts as a translator between two incompatible interfaces. When you need to use an existing class but its interface does not match what your code expects, an adapter wraps the existing class and exposes the expected interface. The adapter translates calls from the target interface to the adaptee's interface. This pattern is extremely common in real-world software: wrapping third-party libraries to match your application's interface, adapting legacy code to work with modern systems, integrating multiple payment providers behind a unified payment interface, and converting data formats between systems. The adapter pattern is the reason you can swap vendors without rewriting business logic. There are two variants: class adapter (using inheritance to extend the adaptee) and object adapter (using composition to wrap the adaptee). Object adapter is more flexible and is the preferred approach in most modern languages.

Bookuvai Implementation

Bookuvai uses adapters extensively for third-party integrations. Every external service (payment, email, SMS, storage) is wrapped in an adapter that implements our internal interface. This lets us swap providers (Stripe to PayPal, SendGrid to Mailgun) without changing business logic.

Key Facts

• Wraps an incompatible interface to match the expected interface
• Enables integration of third-party libraries without coupling to their API
• Object adapter (composition) is preferred over class adapter (inheritance)
• Essential for vendor swapping and legacy system integration
• Often used alongside Strategy pattern for interchangeable providers

Related Terms

• Design Patterns
• Decorator Pattern
• Strategy Pattern

Frequently Asked Questions

What is the difference between Adapter and Facade?

Adapter makes an existing interface match a different expected interface. Facade simplifies a complex subsystem by providing a higher-level unified interface. Adapter translates; Facade simplifies. They can be used together.

When should I create an adapter?

Create an adapter whenever you integrate with a third-party library or service. Even if the external interface seems convenient now, wrapping it in an adapter protects your codebase from API changes and makes vendor switching painless.

Should adapters contain business logic?

No. Adapters should only translate between interfaces. Business logic belongs in services that use the adapted interface. Mixing translation and business logic creates adapters that are hard to test and maintain.