Bridge

The four participants

Bridge has four roles, two per side. The bridge itself is just one field: the abstraction holds a reference to an implementor.

• Abstraction (Remote) — the high-level control that callers use. It holds a device field and delegates real work to it: volumeUp() calls device.setVolume(...).
• Refined Abstraction (AdvancedRemote) — an optional richer subclass of the abstraction. It adds higher-level features like mute() — still built out of implementor calls.
• Implementor interface (Device) — the contract the abstraction talks through: isEnabled(), setVolume(v), getVolume(). This interface is the bridge.
• Concrete Implementors (Tv, Radio, Speaker) — the real platform-specific work. Each implements Device in its own way.

The m × n math

This is why the pattern exists. With one merged hierarchy, every combination is a class: m remote kinds × n device kinds = m × n classes. 2×3 = 6. Add a Projector: 8. Add a Kids remote too: 12. Every new idea on either side multiplies. With Bridge you keep two separate hierarchies: m + n classes. 2+3 = 5. Add a Projector: 6. Add a Kids remote: 7. Every new idea on either side adds exactly one class — and it instantly works with everything on the other side.

interface Device {                    // the Implementor — this IS the bridge
  setVolume(v: number): void;
  getVolume(): number;
}

class Remote {                        // the Abstraction
  constructor(protected device: Device) {}   // 🌉 has-a Device (composition)

  volumeUp(): void {
    this.device.setVolume(this.device.getVolume() + 10);  // delegate
  }
}

class AdvancedRemote extends Remote { // Refined Abstraction
  mute(): void { this.device.setVolume(0); }
}

// Any remote drives any device — pick the pair at runtime:
const remote = new AdvancedRemote(new Tv());   // or new Radio(), new Speaker()
remote.volumeUp();

Notice what Remote doesn't know: whether it's driving a TV or a radio. It only knows the Device interface. That's the bridge doing its job — the remote side and the device side only meet at one thin interface, so each can grow, change, or be swapped without touching the other.

Bridge vs Adapter — designed vs retrofitted

Bridge and [[adapter]] look similar on a diagram — both wrap a call through an interface. The difference is when and why. Adapter is a retrofit: two existing, incompatible interfaces already exist, and you glue them together after the fact. Bridge is planned up front: you design the abstraction and implementation as two hierarchies from the start, on purpose, so both can evolve independently. Adapter fixes a past mismatch; Bridge prevents a future explosion.

Reach for Bridge when two dimensions want to vary

• A class is growing in two independent directions — kind of control × kind of backend, shape × renderer, notification × delivery channel. Two hierarchies joined by a field beat one hierarchy of combos.
• Subclass names start containing an '×' — BasicTVRemote, SqlWindowsLogger, CircleOpenGLRenderer. Compound names are the smell: each word is a dimension that should be its own hierarchy.
• You want to swap the implementation at runtime — hand the same remote a different device mid-program. Inheritance fixes the pairing at compile time; a composed field can be reassigned.
• Platform or backend variations — one API surface over Windows/macOS/Linux implementations, or one storage interface over Postgres/SQLite/in-memory. Callers see the abstraction; the implementor hides the platform.