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
// 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.
Practice what you learned
1. What is the primary purpose of the Adapter pattern?
2. Which implementation strategy is generally preferred for Adapter in modern object-oriented codebases, and why?
3. How does Adapter differ from Facade?
4. In the LegacyGatewayAdapter code example, what role does the adapter play?
5. What is a key risk of overusing the Adapter pattern?
Was this page helpful?
You May Also Like
Decorator Pattern
The Decorator pattern attaches additional responsibilities to an object dynamically by wrapping it in one or more decorator objects that share its interface.
Facade Pattern
The Facade pattern provides a single, simplified interface to a larger, more complex body of subsystem code, making it easier to use without hiding advanced access.
Proxy Pattern
The Proxy pattern provides a surrogate or placeholder object that controls access to another object, adding a layer for lazy loading, access control, caching, or remote communication.
Composite Pattern
The Composite pattern composes objects into tree structures to represent part-whole hierarchies, letting clients treat individual objects and compositions of objects uniformly.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics