# Bridge

> Split a class into two hierarchies — abstraction and implementation — that can vary independently so you don't get a combinatorial explosion of subclasses.

- **Category**: Software Design
- **Subcategory**: structural
- **Canonical URL**: https://designpattern.fyi/patterns/bridge/

---

## Description
**Intent**: Decouple 'what something does' (abstraction) from 'how it does it' (implementation) so both can evolve independently.

**Context**: You have a Shape class and want to support different rendering APIs (OpenGL, Vulkan, Canvas). Or a RemoteControl that works with different Device types. Combining them in a single hierarchy gives you N×M subclasses (CircleOpenGL, CircleVulkan, SquareOpenGL...). It doesn't scale.

**Solution**: Separate into two hierarchies. The Abstraction (RemoteControl) holds a reference to an Implementor interface (Device). Refined Abstractions extend RemoteControl; Concrete Implementations implement Device. Mix and match any combination — no extra subclasses needed.


## Use Cases
Use when you'd otherwise have a class explosion from combining two independently variable dimensions — platform + shape, device + control, renderer + format.



## Implementation Example

```javascript
// Implementation
class Device {
  isEnabled() {}
  enable() {}
  disable() {}
}

class Radio extends Device {
  constructor() { super(); this.on = false; }
  isEnabled() { return this.on; }
  enable() { this.on = true; }
  disable() { this.on = false; }
}

// Abstraction
class RemoteControl {
  constructor(device) { this.device = device; }
  togglePower() {
    if (this.device.isEnabled()) {
      this.device.disable();
    } else {
      this.device.enable();
    }
  }
}

```



## Trade-offs


### Advantages

- Extend abstractions and implementations independently — N+M classes instead of N×M.

- Swap implementations at runtime by changing the reference.




### Considerations & Drawbacks

- Adds indirection that feels over-engineered when there's only one implementation.







---
**Reference**: [Original Source](https://refactoring.guru/design-patterns/bridge)