Bridge pattern

Introduction

Bridge is a structural pattern that separates an abstraction from the implementation that carries it out. Each side can then have its own hierarchy, so two independent dimensions do not multiply into a class for every combination.

TL;DR / mental model: Model “what” and “how” as separate hierarchies, connect them with composition, and let each side evolve without creating an N × M subclass matrix.

Problem and Context

Your notification system has three types: Alert, Reminder, and Marketing. Each type needs to go through three delivery channels: Email, SMS, and Push. The naive approach creates a class per combination:

The two axes (notification type and delivery channel) are tangled into a single inheritance tree. Every new type or channel multiplies the class count. The Bridge pattern separates these axes so they grow independently: 3 types + 3 channels = 6 classes instead of 9. That is the key insight.

When It Helps

Use Bridge when two dimensions vary independently and both may gain new implementations—for example, notification type and delivery channel. If there is only one meaningful axis of variation, inheritance or Strategy is usually simpler.

---

Participants and Structure

Two separate hierarchies connected by composition. Notification is the abstraction (what to send). MessageSender is the implementor (how to send it). Each notification type holds a reference to a MessageSender and delegates delivery to it. Adding a new channel means one new class. Adding a new notification type means one new class. Neither affects the other side.

---

Idiomatic Example and Implementation Notes

The separation starts with two questions: "What varies?" and "What else varies independently?" If the answers are two different things, Bridge keeps those dimensions from tangling.