The Bridge Design Pattern
The Bridge pattern decouples an abstraction from its implementation so that the two can vary independently.
Use the Bridge pattern when you want to separate an object’s abstraction from its implementation, allowing both to evolve independently without affecting each other.
- TypeStructural
- Time ComplexityO(1) Constant Time – The algorithm runs in constant time, irrespective of the input size. Operations like accessing an array element fall into this category.
- Efficiency7
-
Learning Effort
- Average6
- Conceptual7
- Debug and Maintain5
- Implementation6
- Prerequisites5
- Versatility8
Things you should know before you start
- Interfaces Understanding of interfaces in object-oriented programming.
- Composition Understanding of object composition to create complex functionalities.
Minimal Example
Managing shapes and their rendering engines separately in a graphics application.
abstract class Shape {
protected renderer: Renderer;
abstract draw(): void;
}
interface Renderer {
renderShape(): void;
}
const renderer = new OpenGLRenderer();
const shape = new Circle(renderer);
shape.draw();
What’s happening in thie example
In this example, the Shape class uses the Renderer interface to delegate the drawing task. The `clientCode` shows how a Shape object is created with a specific Renderer implementation and then drawn.
How the Bridge Works
The Bridge pattern separates an object’s abstraction from its implementation. This decoupling allows the object’s interface and implementation to be modified independently.
The pattern is particularly useful when you have a proliferating set of classes resulting from a coupled interface and numerous implementations. It aims to simplify the hierarchy and improve maintainability.
Entities in the Bridge Design Pattern
-
AbstractionDefines the abstraction’s interface and maintains a reference to an object of the Implementor type.
- Abstraction has a one-to-one uses relationship with Implementor
-
ImplementorDefines the interface for implementation classes. This interface doesn’t have to correspond directly to the Abstraction’s interface.
- ConcreteImplementor has a one-to-many implements relationship with Implementor
What to watch out for when using or considering this design pattern.
Avoid using the Bridge pattern if the class hierarchies you’re dealing with are not complex and don’t require independent extensibility. The pattern adds complexity to the code.
Design patterns often confused with the Bridge Design Pattern
The following design patterns are often confused with the Bridge
for various resons.
If you’re exploring solutions, have a look through this list and see if
one of these might be a better fit for your problem.
-
Adapter – The Adapter pattern allows objects with incompatible interfaces to collaborate.
The Adapter pattern is similar to the Bridge in the following ways.
- Both are structural design patterns.
- Both aim to simplify interfaces or classes.
- Bridge separates an object’s abstraction from its implementation, while Adapter makes existing interfaces compatible.
- Bridge is more about making abstractions and implementations extensible, whereas Adapter is about making two different interfaces compatible.
-
Composite – The Composite pattern composes objects into tree structures to represent part-whole hierarchies.
The Composite pattern is similar to the Bridge in the following ways.
- Both are structural design patterns.
- Both focus on simplifying complex structures.
- Bridge is used to separate abstraction from implementation, while Composite is used to treat both individual objects and composites uniformly.
- Bridge focuses on abstraction and implementation, whereas Composite focuses on building a tree structure of simple and composite objects.