When building software, we sometimes face a situation where two different parts of the system need to work together. If we put everything into one class hierarchy, we end up with too many classes and a messy structure. The Bridge Pattern helps solve this problem.
There are 2 parts in Bridge design pattern :
-
Abstraction
-
Implementation
It separates what something is (the abstraction) from how it works (the implementation). This way, both can grow or change independently without breaking each other.
Why Use It
-
Keeps code cleaner and avoids creating too many classes.
-
Abstraction and implementation can be changed separately.
-
Increases flexibility and reusability of code.
-
Makes the system loosely coupled.
Elements of the Bridge Design Pattern
The Bridge Pattern has two main parts:
Abstraction
This is the high-level part. It defines what needs to be done but doesn’t worry about the details. Think of it as the “idea” or the outer shell.
Refined Abstraction
This is a more detailed version of the abstraction. It extends the main abstraction to add extra features, while still staying separate from the implementation.
Implementer
This defines how the work will actually be carried out. It’s usually an interface or abstract class that sets the rules for implementation.
Concrete Implementation
These are the real classes that provide the actual working details. They follow the rules defined by the implementer.
UML Diagram
The Problem: Too Many Classes
Let’s say you want to design cars with different types of engines.
-
Car types: SUV, Sedan
-
Engine types: Petrol, Diesel, Electric
If you mix them directly, you’ll need a new class for every combination:
-
SUV with Petrol
-
SUV with Diesel
-
Sedan with Petrol
-
Sedan with Diesel
-
and more if you add Electric…
As the system grows, this quickly gets out of control. You end up with too many subclasses, repeated code, and a design that is hard to maintain. This issue is called class explosion.
How the Bridge Pattern Solves It
The Bridge Pattern solves this by splitting the system into two separate parts:
-
Car (Abstraction Layer): Sedan, SUV
-
Engine (Implementation Layer): Petrol, Diesel, Electric
Instead of building every possible pair, you connect them at runtime.
For example:
-
A Sedan can use a Diesel engine today.
-
The same Sedan can switch to an Electric engine tomorrow.
You don’t need to change the Car or Engine classes to make this happen.
Examples
You’ve likely come across the Bridge Pattern in everyday tech without noticing.
1. Remote Controls and Devices
-
Abstraction: Remote (BasicRemote, AdvancedRemote)
-
Implementation: Devices (TV, Radio, AC)
The same remote can control different devices, and devices can work with different remotes. They evolve separately.
2. UI Elements on Different Operating Systems
-
Abstraction: UI Components (Dropdown, Button)
-
Implementation: Operating System (Windows, Linux, macOS)
The same button or dropdown can look and behave differently depending on the operating system, but the code for the UI component doesn’t need to change.
When to Use the Bridge Pattern
The Bridge Pattern is useful in situations like these:
-
When you need to mix different types of abstractions and implementations without creating a new class for every possible combination.
-
When your class hierarchy is becoming too large and hard to manage.
-
When you want to keep the high-level design (what something does) separate from the low-level details (how it does it).
Use the Bridge Pattern when inheritance alone makes your design messy, and you need a cleaner way to combine features.
Advantages of the Bridge Pattern
-
Follows Single Responsibility Principle: It separates the high-level abstraction from the implementation, so each part has its own job.
-
Follows Open/Closed Principle: You can add new abstractions or new implementations independently without changing existing code.
-
Platform Independence: It helps create features that can work across different platforms easily.
Disadvantages of the Bridge Pattern
-
Can Add Complexity: Introducing new abstraction and implementation layers can make the code harder to read at first.
-
Extra Indirection: Messages have to pass through both abstraction and implementation, which may slightly affect performance.
-
Single Implementation Issues: If an interface only has one implementation, the Bridge may feel unnecessary and harder to manage.
Key Benefits of the Bridge Pattern
-
Promotes Code Reuse: You can reuse both abstractions and implementations without duplicating code.
-
Keeps Abstractions Flexible: High-level parts of the system can change independently of low-level details.
-
Easier to Maintain: Changes in one part don’t break the other, making the system simpler to update.
-
Supports Open/Closed Principle: You can add new features without modifying existing code.
-
Handles Frequent Combinations: Especially useful in large systems where features or platforms change often, like multi-platform UIs, payment gateways, or device controllers.
The Bridge Pattern lets you build scalable systems without rewriting your architecture every time a new combination appears.
Summary
The Bridge Pattern helps separate what a system does from how it does it. Instead of creating a new class for every combination of features, you split the system into two parts: the abstraction (what it is) and the implementation (how it works). This lets you change or add new features without rewriting code. For example, a car type can work with different engines, or a remote can control different devices. It keeps the code clean, flexible, and easier to maintain while avoiding too many classes.