Adapter vs Bridge Pattern
Adapter vs Bridge pattern explained — retrofitting incompatible interfaces vs decoupling abstraction from implementation, with Java examples.
Expected Interview Answer
The Adapter pattern converts an existing incompatible interface into one a client expects, applied after the fact to make unrelated classes work together, while the Bridge pattern is designed up front to decouple an abstraction from its implementation so both can vary independently.
Adapter is a retrofit: you already have a class with the wrong interface (say, a legacy XML parser) and you wrap it so it satisfies a target interface your client code already relies on. Bridge is a proactive structural split: you define an abstraction hierarchy (Shape) and a separate implementation hierarchy (Renderer), connecting them through composition so new abstractions and new implementations can be added on either side without a combinatorial explosion of subclasses. Adapter typically wraps one object and focuses on interface translation; Bridge maintains a long-lived has-a relationship between two hierarchies designed together. In short, Adapter answers “how do I make this fit,” Bridge answers “how do I keep these two things from being welded together.”
- Adapter reuses existing incompatible code without modifying it
- Bridge avoids a class explosion from crossing two independent hierarchies
- Both favor composition over inheritance
- Bridge specifically enables independent extension of abstraction and implementation
AI Mentor Explanation
Adapter is like a plug converter that lets an imported bowling machine, wired for a different voltage, work with the stadium socket — it was built after the mismatch was discovered, purely to make the two fit. Bridge is like the split between “match format” (Test, ODI, T20) and “broadcast technology” (radio, TV, streaming), designed from day one so any format can be paired with any broadcast method without writing a separate class for every combination. One patches an incompatibility after the fact; the other is architected in advance to keep two dimensions independent.
Step-by-Step Explanation
Step 1
Recognize the trigger
Adapter is reached for when an existing class’s interface does not match what the client expects; Bridge is chosen at design time when two hierarchies are expected to vary independently.
Step 2
Adapter: wrap the incompatible class
Create a class implementing the target interface that delegates calls to the adaptee, translating method names and parameters.
Step 3
Bridge: split abstraction from implementation
Define an Abstraction class holding a reference to an Implementor interface, so concrete abstractions and concrete implementors can be combined freely.
Step 4
Verify extensibility
Adapter should let you swap adaptees without touching client code; Bridge should let you add a new abstraction or a new implementor without touching the other hierarchy.
What Interviewer Expects
- A clear statement that Adapter is retrofitted, Bridge is designed upfront
- Mention that Bridge involves two independent hierarchies joined by composition
- Awareness that both avoid modifying existing code and favor composition
- A concrete example distinguishing the intent of each
Common Mistakes
- Treating Adapter and Bridge as interchangeable because both use composition
- Saying Adapter is meant to be designed in advance
- Forgetting that Bridge’s main goal is avoiding a class explosion across two dimensions
- Confusing Bridge with Strategy, which varies one algorithm rather than an entire implementation hierarchy
Best Answer (HR Friendly)
“Adapter is something you use when you already have a class whose interface doesn’t match what your code expects, and you wrap it so the two can work together. Bridge is a decision you make earlier, splitting a concept into two independent hierarchies — like a shape and how it’s rendered — so you can extend either side without a combinatorial mess of classes. Adapter solves a mismatch that already happened; Bridge prevents one hierarchy from tying two concerns together in the first place.”
Code Example
interface MediaPlayer {
void play(String fileName);
}
class LegacyMp4Player {
void playMp4File(String fileName) {
System.out.println("Playing mp4: " + fileName);
}
}
class Mp4Adapter implements MediaPlayer {
private final LegacyMp4Player legacyPlayer = new LegacyMp4Player();
@Override
public void play(String fileName) {
legacyPlayer.playMp4File(fileName);
}
}interface Renderer {
void renderCircle(float radius);
}
class VectorRenderer implements Renderer {
public void renderCircle(float radius) {
System.out.println("Drawing vector circle of radius " + radius);
}
}
abstract class Shape {
protected Renderer renderer;
Shape(Renderer renderer) { this.renderer = renderer; }
abstract void draw();
}
class Circle extends Shape {
float radius;
Circle(Renderer renderer, float radius) {
super(renderer);
this.radius = radius;
}
void draw() { renderer.renderCircle(radius); }
}Follow-up Questions
- Can Adapter be implemented via class inheritance as well as composition?
- How does Bridge differ from Strategy pattern?
- When would you refactor an Adapter into a Bridge?
- What is a two-way adapter and when is it needed?
MCQ Practice
1. Which pattern is primarily used to make two incompatible interfaces work together after the fact?
Adapter wraps an existing incompatible interface so it satisfies what the client expects.
2. The main motivation for the Bridge pattern is to?
Bridge splits abstraction and implementation into two hierarchies connected by composition to avoid a class explosion.
3. Which statement best distinguishes Adapter from Bridge?
Adapter reacts to an existing incompatibility; Bridge is a proactive structural design decision.
Flash Cards
Adapter in one line? — Wraps an existing incompatible interface to match what a client expects.
Bridge in one line? — Decouples an abstraction hierarchy from an implementation hierarchy via composition.
When is Adapter applied? — After the fact, when integrating existing incompatible code.
When is Bridge applied? — At design time, when two dimensions are expected to vary independently.