Bridge Design Pattern in Java: Complete Guide with Examples
Learn the Bridge design pattern in Java with simple explanations and practical examples. This guide covers how to decouple abstraction from implementation using composition, with before-and-after code for beginners and experts.
I've been writing Java for years, and the Bridge pattern is one I keep coming back to. Not because it's fancy—because it saved me from a class explosion in a real payment system. Here's what I've learned.
Why the Bridge Pattern Still Matters in Java
You've built a class hierarchy. It works. Then requirements change: new platforms, new features, new combinations. Suddenly your class explosion looks like a family tree gone wrong.
The Bridge pattern solves this by splitting one tangled hierarchy into two independent ones. It's not about adding more classes—it's about organizing them so they can grow separately without stepping on each other.
Whether you're supporting multiple databases, payment gateways, or remote controls, Bridge keeps your design flexible without the inheritance nightmare.
What is the Bridge Design Pattern?
"Decouple an abstraction from its implementation so that the two can vary independently."
In plain words: Bridge prefers composition over inheritance. Instead of hardcoding every combination into a single class tree, you push implementation details into a separate object hierarchy and connect them through a reference.
The Two Hierarchies
| Role | Responsibility | Example |
|---|---|---|
| Abstraction | High-level control logic | RemoteControl |
| Implementation | Low-level platform-specific work | Device (TV, Radio) |
Bridge pattern structure: RemoteControl and Device hierarchies grow independently through composition.
How to read this diagram (for freshers): Look at the left side — that's the
Abstraction family (remotes). Look at the right side — that's the
Implementation family (devices). The bold red arrow in the middle is the
"bridge." The remote doesn't care which device it is holding — it just calls the
methods defined in the Device interface. Add a new device (say,
Projector)? Only the right side changes. Add a new remote (say,
VoiceRemote)? Only the left side changes. Both sides grow without touching each
other — that's the whole point of the pattern.
The abstraction holds a reference to an implementation object. When the abstraction needs work done, it delegates to that object. Since all implementations share a common interface, they're interchangeable.
Violation: The Class Explosion Nightmare
Imagine you're building a drawing app. You have two shape types (Circle, Square) and two rendering methods (Vector, Raster).
Without Bridge, inheritance forces you to create every combination:
// The explosion begins
class VectorCircle { /* ... */ }
class RasterCircle { /* ... */ }
class VectorSquare { /* ... */ }
class RasterSquare { /* ... */ }
// Add a new shape? Four more classes.
// Add a new renderer? Four more classes.The Problem: Every new shape or renderer multiplies the class count. This is "nested generalizations"—a clear signal you need to split the hierarchy.
Solution: Bridge with Remote Controls and Devices
Let's use the classic remote control example. You have different remotes and different devices. A basic remote should work with a TV or a Radio. An advanced remote should do the same, plus extra features.
Step 1: The Implementation Hierarchy (Devices)
interface Device {
boolean isEnabled();
void enable();
void disable();
int getVolume();
void setVolume(int volume);
int getChannel();
void setChannel(int channel);
}class Tv implements Device {
private boolean on = false;
private int volume = 30;
private int channel = 1;
public boolean isEnabled() { return on; }
public void enable() { on = true; }
public void disable() { on = false; }
public int getVolume() { return volume; }
public void setVolume(int volume) { this.volume = volume; }
public int getChannel() { return channel; }
public void setChannel(int channel) { this.channel = channel; }
}
class Radio implements Device {
// Similar implementation for radio
}Step 2: The Abstraction Hierarchy (Remotes)
class RemoteControl {
protected Device device;
public RemoteControl(Device device) {
this.device = device;
}
public void togglePower() {
if (device.isEnabled()) {
device.disable();
} else {
device.enable();
}
}
public void volumeDown() {
device.setVolume(device.getVolume() - 10);
}
public void volumeUp() {
device.setVolume(device.getVolume() + 10);
}
}Step 3: Refined Abstraction (Advanced Remote)
class AdvancedRemoteControl extends RemoteControl {
public AdvancedRemoteControl(Device device) {
super(device);
}
public void mute() {
device.setVolume(0);
}
}Step 4: Using the Bridge
public class Demo {
public static void main(String[] args) {
// Basic remote with TV
Device tv = new Tv();
RemoteControl basicRemote = new RemoteControl(tv);
basicRemote.togglePower();
basicRemote.volumeUp();
// Advanced remote with Radio
Device radio = new Radio();
AdvancedRemoteControl advancedRemote = new AdvancedRemoteControl(radio);
advancedRemote.togglePower();
advancedRemote.mute();
}
}
What just happened? The RemoteControl hierarchy and the
Device hierarchy grew independently. Adding a new device
(e.g., Projector) requires zero changes to remotes. Adding a new remote
(e.g., VoiceRemote) requires zero changes to devices.
For Beginners: The Power Strip Analogy
Think of a power strip (the abstraction) and different appliances (the implementations). The power strip doesn't care if you plug in a lamp, a phone charger, or a fan. It just provides power. You can add new appliances without rewiring the strip, and you can buy a new power strip without replacing your appliances.
Bridge is the socket. Inheritance would be soldering the appliance directly to the wall.
For Experts: Bridge vs. Adapter (Know the Difference)
This is a common interview trap.
| Aspect | Bridge | Adapter |
|---|---|---|
| Intent | Decouple abstraction from implementation | Make incompatible interfaces work together |
| Timing | Designed upfront | Retrofitted to existing code |
| Structure | Two hierarchies, one reference | One wrapper around one object |
| SOLID | Directly supports OCP and DIP | Supports SRP but is a band-aid |
Rule of thumb: Bridge is planned separation. Adapter is emergency compatibility.
Putting It All Together: The Payment Processing Example
A payment system needs to support multiple gateways (Stripe, PayPal) and multiple payment
types (Subscription, One-Time). Without Bridge, you'd need StripeSubscription,
StripeOneTime, PayPalSubscription, PayPalOneTime—and
it only gets worse with each addition.
The Bridge Structure
| Abstraction (Payment Type) | Implementation (Gateway) |
|---|---|
Payment (abstract) |
PaymentGateway (interface) |
SubscriptionPayment |
StripeGateway |
OneTimePayment |
PayPalGateway |
interface PaymentGateway {
void process(double amount);
}
class StripeGateway implements PaymentGateway {
public void process(double amount) {
System.out.println("Stripe: $" + amount);
}
}
abstract class Payment {
protected PaymentGateway gateway;
public Payment(PaymentGateway gateway) {
this.gateway = gateway;
}
public abstract void pay(double amount);
}
class SubscriptionPayment extends Payment {
public SubscriptionPayment(PaymentGateway gateway) {
super(gateway);
}
public void pay(double amount) {
gateway.process(amount * 0.9); // 10% discount
}
}
class OneTimePayment extends Payment {
public OneTimePayment(PaymentGateway gateway) {
super(gateway);
}
public void pay(double amount) {
gateway.process(amount);
}
}
Now adding CryptoGateway or InstallmentPayment means
one new class, not a matrix of combinations.
Personal note: I once inherited a codebase with
StripeSubscription, StripeOneTime,
PayPalSubscription, and PayPalOneTime.
Adding Apple Pay would have meant four more classes. That's when I
refactored to Bridge—and the next gateway took one class, not four.
Frequently Asked Questions
What is the Bridge design pattern in Java?
Bridge is a structural pattern that splits a large class or closely related classes into two independent hierarchies: abstraction and implementation. They connect through composition, allowing both to evolve without affecting each other.
When should I use the Bridge pattern?
Use Bridge when you have a proliferation of classes from combining two dimensions (e.g., shapes × renderers, payment types × gateways), or when you want to switch implementations at runtime.
How is Bridge different from Strategy?
Both use composition and delegation. Strategy swaps algorithms at runtime within a single class. Bridge separates two entire hierarchies that would otherwise be fused by inheritance. Bridge is structural; Strategy is behavioral.
Does Bridge support SOLID principles?
Directly. It supports Open/Closed (extend either hierarchy without modifying existing code) and Dependency Inversion (abstractions don't depend on concrete implementations).
Is Bridge overkill for small projects?
Yes, often. If you only have one implementation, or the dimensions won't grow, inheritance is simpler. Bridge pays off when you anticipate independent evolution on both sides.
Your Bridge Checklist
Before committing to a class hierarchy, ask:
- Am I multiplying classes? If you have
TypeA_Impl1,TypeA_Impl2,TypeB_Impl1—stop and consider Bridge. - Do I have two dimensions? If shapes and renderers both grow independently, split them.
- Will implementations change? If you might swap databases or payment gateways, design for it now.
- Am I ready for composition? Bridge requires accepting a reference in the constructor, not hardcoding it.
Start small. Refactor one exploding hierarchy. The clarity compounds.
Conclusion
The Bridge pattern isn't about complexity—it's about controlled growth. When two dimensions of your system need to evolve independently, Bridge gives them room to breathe. It trades a small upfront design decision for long-term freedom from class explosion.
I'll be honest: I don't use Bridge in every project. Small scripts don't need it. But for anything that touches payments, databases, or multiple platforms, it has saved me from rewriting the same logic over and over. Start with the problem, not the pattern. If you find yourself writing the same class name with different suffixes, Bridge is probably the answer.
Related topics: SOLID Principles in Java, Adapter Design Pattern, Strategy Design Pattern, Java Composition vs Inheritance, Structural Design Patterns
No comments:
Post a Comment