Bridge

Bridge has the worst official description of any pattern. "Decouple an abstraction from its implementation so that the two can vary independently" is accurate and tells you nothing about when you would want that.

The situation it addresses is concrete and recognisable: you have two independent reasons for a class to vary, and expressing both with inheritance multiplies them.

The multiplication

A notification system has kinds of notification — alert, digest, reminder — and channels — email, SMS, push. With inheritance you must pick one dimension as the base and enumerate the other:

class Notification {}
class AlertNotification extends Notification {}
class EmailAlertNotification extends AlertNotification {}
class SmsAlertNotification extends AlertNotification {}
class PushAlertNotification extends AlertNotification {}
class EmailDigestNotification extends DigestNotification {}
// 3 kinds × 3 channels = 9 classes

Three by three is nine. A fourth channel makes it twelve; a fourth kind makes it sixteen. Worse, every channel's delivery logic is duplicated across every kind that uses it.

classDiagram
    class Notification {
        #channel: Channel
        +send(user) void
        #compose(user)* Content
    }
    class AlertNotification {
        #compose(user) Content
    }
    class DigestNotification {
        #compose(user) Content
    }
    class Channel {
        <<interface>>
        +deliver(recipient, content) void
    }
    class EmailChannel {
        +deliver(recipient, content) void
    }
    class SmsChannel {
        +deliver(recipient, content) void
    }
    Notification <|-- AlertNotification
    Notification <|-- DigestNotification
    Channel <|.. EmailChannel
    Channel <|.. SmsChannel
    Notification o-- Channel

Three kinds plus three channels is six classes rather than nine, and the gap widens as either side grows. Bridge converts a product into a sum.

class Notification {
  constructor(channel) { this.channel = channel; }
  send(user) { this.channel.deliver(user, this.compose(user)); }
}

class AlertNotification extends Notification {
  compose(user) { return { title: 'Incident', body: this.incident.summary, urgency: 'high' }; }
}

new AlertNotification(new SmsChannel()).send(user);

The distinction that actually matters

Bridge, Strategy and Adapter all end up as "an object holds another object", and teams spend more time arguing about which one they wrote than the distinction is worth. The differences with consequences:

The Bridge-specific signal is that both sides are hierarchies. If one side is a single interface with implementations and the other side is one class, you have Strategy. If both sides genuinely have families — several notification kinds and several channels — you have Bridge, and its contribution is preventing their product.

A second signal is timing. A strategy is usually chosen per call; a bridge is typically set once at construction and describes what the object is.

The hard part: designing the seam

Spotting the multiplication is easy. The difficulty is deciding what the implementation side is allowed to know, and this is where Bridge designs fail.

Suppose Channel.deliver(recipient, message) takes a composed string. That works until SMS needs a 160-character limit, push needs a title and a payload, and email needs a subject and an HTML alternative. The seam was designed around the easiest channel, and every real channel now needs something it cannot express.

Two ways out, with different costs:

Widen the seam. deliver(recipient, { subject, body, html, ttl }) — every channel receives everything and ignores what it does not use. Simple, and it degrades into a bag of optional fields nobody can reason about.

Move rendering to the implementation side. The notification supplies structured content — a title, a body, an urgency — and each channel renders it as it sees fit. SMS truncates, push maps urgency to a priority, email builds a subject line.

The second is usually right, and the principle generalises: the seam should carry meaning, not formatting. A seam expressed in the vocabulary of one implementation will not survive the second one.

Where it genuinely appears

Rendering across backends. A document model rendered to PDF, HTML or plain text, where document kinds also vary.

Persistence across stores. Several aggregate types persisted to several backends, where you refuse to write one class per pairing.

Platform abstraction. Several kinds of operation over several underlying platforms — the classic operating-system case, and still the clearest one.

Payment kinds over providers. One-off charges, subscriptions and refunds across several gateways: three by three, and every cell would otherwise be a class.

Check your understanding

Common mistakes

Applying it with one implementation. The seam becomes a guess shaped around the only case you have.

A seam carrying formatting instead of meaning. Pre-rendered output cannot be un-rendered by the next implementation.

Arguing about whether it is Bridge or Strategy. If both sides are hierarchies it is Bridge; otherwise the distinction is not worth a meeting.

Letting the implementation interface grow a method per implementation. That is the product returning through the back door.

Leaking implementation types through the abstraction. If a caller must know which channel it holds, the dimensions were never separated.

Using it where the dimensions are not independent. If certain kinds only work with certain implementations, the product was never full and Bridge over-generalises.

Practice

Key takeaways

• Bridge separates two independently varying dimensions, converting a product of classes into a sum.
• The countable test: if inheritance over both dimensions gives kinds × implementations, Bridge is the fix.
• Distinguish from Strategy (one varying behaviour, chosen per call) and Adapter (translation, no variation).
• The hard part is the seam. It must carry meaning, not formatting, or the second implementation cannot use it.
• Do not introduce it before both dimensions have real variants — a seam designed against one implementation is a guess, and usually a wrong one.
• If the dimensions are not fully independent, the grid is sparse, and Bridge forces implementations to answer questions they have no answer to.
• Sometimes the real problem is duplication, not a missing abstraction — deduplicate first and see what is left.

Further reading

• Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994).
• Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal, Pattern-Oriented Software Architecture, Volume 1 (Wiley, 1996).
• Sandi Metz, Practical Object-Oriented Design in Ruby (Addison-Wesley, 2012) — choosing what to depend on.
• Martin Fowler, Refactoring, second edition (Addison-Wesley, 2018) — replacing a subclass explosion with delegation.
• Barbara Liskov and John Guttag, Program Development in Java (Addison-Wesley, 2000) — abstraction boundaries and what they must preserve.