Adapter Pattern

Analogy categoryAnalogies

What the Adapter Pattern Solves

The Adapter pattern is a structural design pattern that wraps an existing class with a new interface so it becomes compatible with the interface a client already expects. Instead of rewriting either side, you insert a thin translator object between them: the client calls a method on the adapter, and the adapter internally calls the equivalent method on the wrapped (adaptee) object, converting parameters, return types, or call sequences as needed. This is invaluable when integrating third-party libraries, legacy code, or external APIs whose interfaces you cannot change.

🏏

Cricket analogy: When Rashid Khan, a leg-spinner trained in Afghanistan's domestic circuit, joins an IPL franchise, the coaching staff doesn't rewrite his bowling action; they adapt team instructions (field placements, over allocations) to fit his existing skill set, just like an adapter wraps an unchanged class.

Object Adapters vs. Class Adapters

There are two structural variants. The object adapter uses composition: the adapter holds a reference to an instance of the adaptee and delegates calls to it, which works in any language and lets one adapter wrap multiple adaptee subclasses at runtime. The class adapter uses multiple inheritance (or, in single-inheritance languages, interface implementation plus a held reference) to inherit from both the target interface and the adaptee, overriding methods directly. Most modern object-oriented codebases favor the object adapter because composition avoids the fragility of multiple inheritance and can adapt subclasses polymorphically.

🏏

Cricket analogy: Composition-based adapting is like a franchise hiring a dedicated fielding coach who translates a bowler's raw pace into a specific death-over strategy, rather than trying to genetically 'inherit' both a fast bowler's and a spinner's attributes into one hybrid player.

A Worked Example

typescript

// Target interface the client (checkout module) expects
interface PaymentProcessor {
  charge(amountInCents: number, currency: string): Promise<{ success: boolean; txnId: string }>;
}

// Adaptee: a legacy third-party SDK with an incompatible interface
class LegacyGatewaySDK {
  async submitPayment(dollars: number, isoCurrency: string): Promise<{ ok: boolean; reference: string }> {
    // pretend network call to legacy gateway
    return { ok: true, reference: 'LEGACY-REF-001' };
  }
}

// Object Adapter: wraps the adaptee, implements the target interface
class LegacyGatewayAdapter implements PaymentProcessor {
  constructor(private legacySdk: LegacyGatewaySDK) {}

  async charge(amountInCents: number, currency: string) {
    const dollars = amountInCents / 100;
    const result = await this.legacySdk.submitPayment(dollars, currency);
    return { success: result.ok, txnId: result.reference };
  }
}

// Client code only ever depends on PaymentProcessor
async function checkout(processor: PaymentProcessor) {
  const receipt = await processor.charge(4999, 'USD');
  console.log(receipt.success ? 'Paid' : 'Failed', receipt.txnId);
}

checkout(new LegacyGatewayAdapter(new LegacyGatewaySDK()));

Adapter is easy to confuse with Facade because both wrap other code, but their intent differs: Adapter makes an existing interface match one the client already expects (one-to-one translation, no simplification implied), while Facade introduces a brand-new, simplified interface over a whole subsystem of many classes to hide complexity.

When to Reach for It, and When Not To

Use Adapter when you need to integrate a class whose interface doesn't match what your code expects and you either cannot or should not modify that class's source, such as a vendor SDK, a generated client, or legacy code frozen by a support contract. Avoid reaching for it prematurely if you control both sides of the interface: it is almost always simpler to just change the method signature or rename the class than to add an indirection layer. Overusing adapters, especially chaining adapter-of-adapter-of-adapter, produces a maintenance trap where tracing an actual method call requires jumping through several translation layers.

🏏

Cricket analogy: A team doesn't build a translator layer for a domestic player who already speaks the coach's tactical language; adapters are reserved for genuinely incompatible cases, like fitting an overseas T10 specialist's franchise-league mindset into a five-day Test match rotation.

Watch for 'adapter chains' where Adapter A wraps Adapter B which wraps the real object. Each layer adds a stack frame and cognitive overhead. If you find yourself stacking adapters, consider whether the target interface itself needs to evolve, or whether a Facade over the whole chain would be clearer than three thin translation layers.

Adapter converts one class's existing interface into another interface a client already expects, without modifying either side.
Object adapters use composition (holding a reference to the adaptee) and are preferred in most modern codebases for flexibility.
Class adapters use inheritance to satisfy both interfaces at once, but require multiple inheritance and are less flexible.
Adapter is a one-to-one translation layer; Facade simplifies access to an entire subsystem of many classes.
The pattern is ideal for integrating third-party SDKs, legacy code, or external APIs you cannot change.
Overusing adapters, especially chaining them, hides the real call path and hurts maintainability.
If you control both interfaces, refactor directly instead of introducing an adapter.