Bridge Design Pattern

Definition
Bridge decouples an abstraction from its implementations, so that both can very independently.
1. Abstraction : High level layer ( eg: Car )
2. Implementations : Low level layer ( eg: Engine )

🎯 The Problem

Without Bridge, you might create classes for every combination:

ElectricSUV, ElectricSedan, PetrolSUV, PetrolSedan, DieselSUV, DieselSedan, … → n × m classes

This quickly becomes unmanageable as you add new vehicle types or engine types.

🏗️ Bridge to the Rescue

1. Define the Abstraction (the “high‑level” API)

<<abstract>>  
Car  
- Engine engine  
+ drive()

Concrete Abstractions:

SUV extends Car
Sedan extends Car

They implement drive() by delegating to engine.start() under the hood.

2. Define the Implementor (the “low‑level” API)

<<abstract>>  
Engine  
+ start()

Concrete Implementors:

ElectricEngine implements Engine
PetrolEngine implements Engine
DieselEngine implements Engine

Each start() contains engine‑specific logic.

3. Wiring It Up

Engine e = new ElectricEngine();
Car mySUV = new SUV(e);
mySUV.drive();       // “Electric engine started → SUV is driving”

Car mySedan = new Sedan(new DieselEngine());
mySedan.drive();     // “Diesel engine started → Sedan is driving”

You only need n + m classes (not n × m).

📐 Standard UML

Client → Abstraction

            <<abstract>>             <<abstract>>
            +-----------+────────────▶+-----------+
            | Car       | uses-a      | Engine    |
            | + drive() |             | + start() |
            +-----▲-----+             +-----▲-----+
                  |                         |
        +---------+---------+    +----------+----------+
        |                   |    |                     |
    SUV (Abstraction)   Sedan    ElectricEngine   PetrolEngine
    + drive()           + drive() + start()        + start()

Abstraction holds a reference to Implementor.
Concrete versions of each can vary independently.

⚔️ Bridge vs. Strategy

Aspect	Bridge Pattern	Strategy Pattern
Intent	Decouple two independent hierarchies (e.g., Car & Engine)	Encapsulate interchangeable algorithms/behaviors (e.g., sorting strategies)
Relationship	Has‑a Implementor (stable abstraction ↔ implementation)	Uses‑a Strategy (context delegates to strategy)
Extensibility	+ Add new Abstractions or Implementors without cross-product explosion	+ Swap behaviors at runtime; easy to add new strategies
When to Use	Two dimensions of variation that should evolve independently	One dimension of behavior variation at runtime
Example	Vehicles ↔ Engine types	Payment calculation strategies, sorting algorithms

Bridge manages two orthogonal hierarchies.
Strategy provides a single family of interchangeable algorithms to a context.

🌟 When to Use Bridge

You foresee independent growth in two axes (e.g., UI toolkit vs. rendering backend, document formats vs. export channels).
You want to avoid combinatorial explosion of subclasses.
You need to swap implementations dynamically or provide multiple implementations at once.

System Design ( Day - 60 )