LESSON 5.2

Bridge

Decouple an abstraction from its implementation so that the two can vary independently.

15 min read

Real-world analogy

A universal television remote control operates across multiple entertainment devices (Sony, Samsung, LG). The remote's control interface (power toggle, volume slider, channel stepper) represents the high-level abstraction. The infrared or Bluetooth signal transmission hardware and vendor-specific protocol represent the low-level implementation. Instead of manufacturing a separate physical remote for every single TV model and brand combination, the remote connects to the device protocol across a bridge.

The problem

You are building a cross-platform graphics rendering engine. You need to support basic geometric shapes (Circle, Square) across multiple rendering backends (VectorRenderer for SVG export, RasterRenderer for bitmap pixel screens).

If you use pure class inheritance, you must create a concrete class for every shape and renderer combination:

output.txt

1 Shape
2 ├── VectorCircle
3 ├── RasterCircle
4 ├── VectorSquare
5 └── RasterSquare

Text · 5 lines

UTF-8

Adding a third shape (Triangle) requires two new classes. Adding a third renderer (DirectXRenderer) requires three new classes. For $N$ shapes and $M$ renderers, you must maintain $N \times M$ classes.

This geometric class proliferation violates the Single Responsibility Principle by tangling domain geometry with platform-specific drawing routines.

The solution

The Bridge pattern splits a monolithic inheritance hierarchy into two independent, orthogonal hierarchies:

Abstraction: High-level control layer (Shape, RefinedAbstraction like Circle).
Implementation: Low-level platform layer (Renderer, ConcreteImplementor like VectorRenderer).

The Abstraction holds a reference (the "bridge") to an Implementor interface and delegates rendering operations to it.

Abstraction (Shape): Defines high-level shape operations and retains a reference to Renderer.
Refined Abstraction (Circle, Square): Extends Shape with domain-specific shape logic.
Implementor (Renderer): Declares low-level drawing primitives (renderCircle, renderSquare).
Concrete Implementors (VectorRenderer, RasterRenderer): Implements the platform-specific drawing primitives.

Laying out the diagram…

Shape holds a reference to Renderer (the bridge). Both hierarchies can grow independently.

Step-by-step implementation

Step 1: Define the implementor interface

Declare the low-level primitive operations that concrete platforms must satisfy.

1 class Renderer {
2   renderCircle(radius) {
3     throw new Error("renderCircle() must be implemented");
4   }
5   renderSquare(side) {
6     throw new Error("renderSquare() must be implemented");
7   }
8 }

1 public class Example {
2     interface Renderer

JavaScript · 8 lines

UTF-8

Step 2: Implement concrete platforms

Provide platform-specific implementations of the rendering primitives.

Step 3: Create the abstraction and refined shapes

The abstraction wraps the Renderer bridge reference. Refined shapes invoke the bridge.

The complete example

Here is the complete runnable implementation demonstrating shapes decoupled from renderers.

Output

1 VectorRenderer: <circle r="10" />
2 RasterRenderer: Drawing square raster grid side 25
3 RasterRenderer: Drawing circle pixels with radius 10

Text · 3 lines

UTF-8

Variations

Abstraction × implementation (avoiding class explosion)

The primary reason to employ Bridge is avoiding exponential class proliferation:

Without Bridge: Adding $N$ abstractions across $M$ platforms requires $N \times M$ concrete classes.
With Bridge: Adding $N$ abstractions across $M$ platforms requires only $N + M$ classes.

For example, supporting 10 shapes across 4 renderers without Bridge requires 40 classes. With Bridge, it requires 10 shape classes and 4 renderer classes (14 classes total).

Remotes × devices

Another classic variation is device hardware control:

Abstractions: BasicRemote, AdvancedRemote (with mute and channel history).
Implementations: SonyTV, RokuStreamer, AppleTV.

The remote abstraction provides high-level user commands, delegating low-level power and frequency modulation calls across the bridge to the device driver.

Where you've already used it

Java Database Connectivity (JDBC): java.sql.Connection and Statement act as the high-level Abstraction. Concrete database drivers (PostgreSQL Driver, MySQL Connector) act as the Implementors.
Java AWT Peers: GUI components (Button, Window) serve as abstractions delegating drawing and events to OS-specific peer implementations (X11ButtonPeer, WindowsButtonPeer).
SLF4J: Simple Logging Facade for Java exposes logging abstractions (Logger), bridging to concrete logging engines (Logback, Log4j2).
Cross-Platform UI Frameworks: Flutter and React Native separate component layout abstractions from platform rendering pipelines on iOS and Android.

Pros and cons

Advantages

Decoupled Evolution: Abstraction and platform implementations can be extended independently without recompiling the other hierarchy.
Eliminates Class Explosion: Replaces $N \times M$ class explosion with $N + M$ linear growth.
Open/Closed Principle: New abstractions and new platforms are added without modifying existing code.
Runtime Binding: Abstractions can switch their underlying implementor dynamically at runtime.

Disadvantages

Increased Complexity: Introduces multiple interfaces and indirection layers into codebases that might only ever have one platform.
Initial Design Overhead: Requires anticipating orthogonal dimensions upfront during architecture planning.

When not to use it

Do not apply Bridge if your domain will only ever have a single, static implementation. If you have Circle and it will only ever render to an HTML5 <canvas>, introducing a Renderer implementor hierarchy is premature overengineering.

Pattern	Purpose	When Decided
Bridge	Decouples abstraction and implementation independently	Upfront architecture design
Adapter	Connects incompatible existing interfaces	After systems are already built
Strategy	Swaps interchangeable algorithms dynamically	Focuses on behavioral algorithms, not structural hierarchies
Abstract Factory	Creates families of matching products	Can be used alongside Bridge to instantiate matching implementors

Interview questions

What is the core problem solved by the Bridge pattern? Bridge prevents a Cartesian product class explosion ($N \times M$) by decoupling an abstraction from its implementation via composition, scaling linearly as $N + M$.

How does Bridge differ from Strategy? While both use composition, Bridge is a structural pattern separating an abstraction hierarchy from an implementation hierarchy. Strategy is a behavioral pattern swapping interchangeable algorithms on a single context class.

Can the Implementor in a Bridge pattern be swapped at runtime? Yes. Because the bridge is maintained via an object reference on the abstraction, the implementor can be swapped dynamically (for example, switching from a VectorRenderer to a RasterRenderer during low-power mode).

How does JDBC illustrate the Bridge pattern? JDBC client code interacts with standard java.sql interfaces (Abstraction). Concrete JDBC vendor drivers implement these interfaces for Postgres, MySQL, or Oracle (Implementor), allowing application code to remain database-agnostic.

Try it

Logging Framework LLD

Compose structured logging, redaction and bounded asynchronous output.

Check your understanding

1.What is the primary problem that the Bridge pattern solves?
2.How are the Abstraction and Implementor connected in the Bridge pattern?
3.How does Bridge differ fundamentally from Adapter?
4.Which real-world ecosystem architecture is a canonical example of the Bridge pattern?
5.When is the Bridge pattern considered an anti-pattern or premature overengineering?

Practice it

Logging Framework LLDCompose structured logging, redaction and bounded asynchronous output.In-memory File System LLDModel a directory tree with path resolution, safe moves and consistent mutations.

Your notes

5. Structural patterns

LESSON 5.2

Bridge

Decouple an abstraction from its implementation so that the two can vary independently.

15 min read

Real-world analogy

The problem

If you use pure class inheritance, you must create a concrete class for every shape and renderer combination:

output.txt

1 Shape
2 ├── VectorCircle
3 ├── RasterCircle
4 ├── VectorSquare
5 └── RasterSquare

Text · 5 lines

UTF-8

This geometric class proliferation violates the Single Responsibility Principle by tangling domain geometry with platform-specific drawing routines.

The solution

The Bridge pattern splits a monolithic inheritance hierarchy into two independent, orthogonal hierarchies:

Abstraction: High-level control layer (Shape, RefinedAbstraction like Circle).
Implementation: Low-level platform layer (Renderer, ConcreteImplementor like VectorRenderer).

The Abstraction holds a reference (the "bridge") to an Implementor interface and delegates rendering operations to it.

Abstraction (Shape): Defines high-level shape operations and retains a reference to Renderer.
Refined Abstraction (Circle, Square): Extends Shape with domain-specific shape logic.
Implementor (Renderer): Declares low-level drawing primitives (renderCircle, renderSquare).
Concrete Implementors (VectorRenderer, RasterRenderer): Implements the platform-specific drawing primitives.

Laying out the diagram…

Shape holds a reference to Renderer (the bridge). Both hierarchies can grow independently.

Step-by-step implementation

Step 1: Define the implementor interface

Declare the low-level primitive operations that concrete platforms must satisfy.

1 class Renderer {
2   renderCircle(radius) {
3     throw new Error("renderCircle() must be implemented");
4   }
5   renderSquare(side) {
6     throw new Error("renderSquare() must be implemented");
7   }
8 }

1 public class Example {
2     interface Renderer

JavaScript · 8 lines

UTF-8

Step 2: Implement concrete platforms

Provide platform-specific implementations of the rendering primitives.

Step 3: Create the abstraction and refined shapes

The abstraction wraps the Renderer bridge reference. Refined shapes invoke the bridge.

The complete example

Here is the complete runnable implementation demonstrating shapes decoupled from renderers.

Output

1 VectorRenderer: <circle r="10" />
2 RasterRenderer: Drawing square raster grid side 25
3 RasterRenderer: Drawing circle pixels with radius 10

Text · 3 lines

UTF-8

Variations

Abstraction × implementation (avoiding class explosion)

The primary reason to employ Bridge is avoiding exponential class proliferation:

Without Bridge: Adding $N$ abstractions across $M$ platforms requires $N \times M$ concrete classes.
With Bridge: Adding $N$ abstractions across $M$ platforms requires only $N + M$ classes.

For example, supporting 10 shapes across 4 renderers without Bridge requires 40 classes. With Bridge, it requires 10 shape classes and 4 renderer classes (14 classes total).

Remotes × devices

Another classic variation is device hardware control:

Abstractions: BasicRemote, AdvancedRemote (with mute and channel history).
Implementations: SonyTV, RokuStreamer, AppleTV.

The remote abstraction provides high-level user commands, delegating low-level power and frequency modulation calls across the bridge to the device driver.

Where you've already used it

Java Database Connectivity (JDBC): java.sql.Connection and Statement act as the high-level Abstraction. Concrete database drivers (PostgreSQL Driver, MySQL Connector) act as the Implementors.
Java AWT Peers: GUI components (Button, Window) serve as abstractions delegating drawing and events to OS-specific peer implementations (X11ButtonPeer, WindowsButtonPeer).
SLF4J: Simple Logging Facade for Java exposes logging abstractions (Logger), bridging to concrete logging engines (Logback, Log4j2).
Cross-Platform UI Frameworks: Flutter and React Native separate component layout abstractions from platform rendering pipelines on iOS and Android.

Pros and cons

Advantages

Decoupled Evolution: Abstraction and platform implementations can be extended independently without recompiling the other hierarchy.
Eliminates Class Explosion: Replaces $N \times M$ class explosion with $N + M$ linear growth.
Open/Closed Principle: New abstractions and new platforms are added without modifying existing code.
Runtime Binding: Abstractions can switch their underlying implementor dynamically at runtime.

Disadvantages

Increased Complexity: Introduces multiple interfaces and indirection layers into codebases that might only ever have one platform.
Initial Design Overhead: Requires anticipating orthogonal dimensions upfront during architecture planning.

When not to use it

Pattern	Purpose	When Decided
Bridge	Decouples abstraction and implementation independently	Upfront architecture design
Adapter	Connects incompatible existing interfaces	After systems are already built
Strategy	Swaps interchangeable algorithms dynamically	Focuses on behavioral algorithms, not structural hierarchies
Abstract Factory	Creates families of matching products	Can be used alongside Bridge to instantiate matching implementors

Pattern Kata

Bridge: logging and formatting

Decouple logger abstraction levels (info, warn, alert) from output format implementations (JSON, Text) using the Bridge pattern.

~15 min practice

JSkata.js

JavaScript752 / 40,000 chars

Click Run tests to evaluate your solution against the behavior and structural test suite.

Interview questions

Try it

Logging Framework LLD

Compose structured logging, redaction and bounded asynchronous output.

Check your understanding

1.What is the primary problem that the Bridge pattern solves?
2.How are the Abstraction and Implementor connected in the Bridge pattern?
3.How does Bridge differ fundamentally from Adapter?
4.Which real-world ecosystem architecture is a canonical example of the Bridge pattern?
5.When is the Bridge pattern considered an anti-pattern or premature overengineering?

Practice it

Logging Framework LLDCompose structured logging, redaction and bounded asynchronous output.In-memory File System LLDModel a directory tree with path resolution, safe moves and consistent mutations.

Your notes

1 // Implementor interface 2 class Renderer { 3 renderCircle(radius) { 4 throw new Error("renderCircle() must be implemented"); 5 } 6 renderSquare(side) { 7 throw new Error("renderSquare() must be implemented"); 8 } 9 } 10 11 // Concrete Implementor 1 12 class VectorRenderer extends Renderer { 13 renderCircle(radius) { 14 console.log(`VectorRenderer: <circle r="${radius}" />`); 15 } 16 renderSquare(side) { 17 console.log(`VectorRenderer: <rect width="${side}" height="${side}" />`); 18 } 19 } 20 21 // Concrete Implementor 2 22 class RasterRenderer extends Renderer { 23 renderCircle(radius) { 24 console.log(`RasterRenderer: Drawing circle pixels with radius ${radius}`); 25 } 26 renderSquare(side) { 27 console.log(`RasterRenderer: Drawing square raster grid side ${side}`); 28 } 29 } 30 31 // Abstraction 32 class Shape { 33 #renderer; 34 35 constructor(renderer) { 36 this.#renderer = renderer; 37 } 38 39 get renderer() { 40 return this.#renderer; 41 } 42 43 draw() { 44 throw new Error("draw() must be implemented"); 45 } 46 resize(factor) { 47 throw new Error("resize() must be implemented"); 48 } 49 } 50 51 // Refined Abstraction 1 52 class Circle extends Shape { 53 #radius; 54 55 constructor(renderer, radius) { 56 super(renderer); 57 this.#radius = radius; 58 } 59 60 draw() { 61 this.renderer.renderCircle(this.#radius); 62 } 63 64 resize(factor) { 65 this.#radius *= factor; 66 } 67 } 68 69 // Refined Abstraction 2 70 class Square extends Shape { 71 #side; 72 73 constructor(renderer, side) { 74 super(renderer); 75 this.#side = side; 76 } 77 78 draw() { 79 this.renderer.renderSquare(this.#side); 80 } 81 82 resize(factor) { 83 this.#side *= factor; 84 } 85 } 86 87 // Demonstration 88 const vector = new VectorRenderer(); 89 const raster = new RasterRenderer(); 90 91 const circle = new Circle(vector, 10); 92 const square = new Square(raster, 25); 93 94 circle.draw(); 95 square.draw(); 96 97 // Re-bridge with different backend at runtime 98 const rasterCircle = new Circle(raster, 10); 99 rasterCircle.draw();

1 public class Example { 2 // Implementor 3 interface Renderer { 4 void renderCircle(double radius); 5 void renderSquare(double side); 6 } 7 8 // Concrete Implementor 1 9 static class VectorRenderer implements Renderer { 10 @Override 11 public void renderCircle(double radius) { 12 System.out.println("VectorRenderer: <circle r=\"" + radius + "\" />"); 13 } 14 @Override 15 public void renderSquare(double side) { 16 System.out.println("VectorRenderer: <rect width=\"" + side + "\" height=\"" + side + "\" />"); 17 } 18 } 19 20 // Concrete Implementor 2 21 static class RasterRenderer implements Renderer { 22 @Override 23 public void renderCircle(double radius) { 24 System.out.println("RasterRenderer: Drawing circle pixels with radius " + radius); 25 } 26 @Override 27 public void renderSquare(double side) { 28 System.out.println("RasterRenderer: Drawing square raster grid side " + side); 29 } 30 } 31 32 // Abstraction 33 abstract static class Shape { 34 protected final Renderer renderer; 35 36 protected Shape(Renderer renderer) { 37 this.renderer = renderer; 38 } 39 40 public abstract void draw(); 41 } 42 43 // Refined Abstraction 1 44 static class Circle extends Shape { 45 private final double radius; 46 47 public Circle(Renderer renderer, double radius) { 48 super(renderer); 49 this.radius = radius; 50 } 51 52 @Override 53 public void draw() { 54 renderer.renderCircle(radius); 55 } 56 } 57 58 // Refined Abstraction 2 59 static class Square extends Shape { 60 private final double side; 61 62 public Square(Renderer renderer, double side) { 63 super(renderer); 64 this.side = side; 65 } 66 67 @Override 68 public void draw() { 69 renderer.renderSquare(side); 70 } 71 } 72 73 public static void main(String[] args) { 74 Renderer vector = new VectorRenderer(); 75 Renderer raster = new RasterRenderer(); 76 77 Shape circle = new Circle(vector, 10); 78 Shape square = new Square(raster, 25); 79 80 circle.draw(); 81 square.draw(); 82 83 Shape rasterCircle = new Circle(raster, 10); 84 rasterCircle.draw(); 85 } 86 }

Real-world analogy

The problem

The solution

Step-by-step implementation

Step 1: Define the implementor interface

Step 2: Implement concrete platforms

Step 3: Create the abstraction and refined shapes

The complete example

Variations

Abstraction × implementation (avoiding class explosion)

Remotes × devices

Where you've already used it

Pros and cons

Advantages

Disadvantages

When not to use it

Related patterns

Interview questions

Check your understanding

Practice it

Real-world analogy

The problem

The solution

Step-by-step implementation

Step 1: Define the implementor interface

Step 2: Implement concrete platforms

Step 3: Create the abstraction and refined shapes

The complete example

Variations

Abstraction × implementation (avoiding class explosion)

Remotes × devices

Where you've already used it

Pros and cons

Advantages

Disadvantages

When not to use it

Related patterns

Bridge: logging and formatting

Interview questions

Check your understanding

Practice it

Bridge: logging and formatting