Bridge pattern explained with examples

Intent

Decouple an abstraction from its implementation so that the two can vary independently. Bridge is one of the seven structural patterns in the Gang of Four (GoF) book, where it is also known as Handle/Body.

The problem it solves

Imagine an app that sends two kinds of messages, alerts and reminders, through two channels, email and SMS. If you model this with inheritance, you get EmailAlert, SmsAlert, EmailReminder and SmsReminder. Add a push channel and a digest message, and you need nine classes. Every new type on either side multiplies the total.

The real problem is that the class hierarchy mixes two independent questions: what the message is, and how it is delivered. Bridge separates them into two hierarchies and connects them with a reference, so the total grows by addition instead of multiplication.

Structure and participants

TypeScript implementation

// Implementor: how a message is delivered.
interface Sender {
  deliver(to: string, subject: string, body: string): string;
}

class EmailSender implements Sender {
  deliver(to: string, subject: string, body: string) { return `email ${to} | ${subject} | ${body}`; }
}

class SmsSender implements Sender {
  deliver(to: string, subject: string, body: string) { return `sms ${to} | ${subject}: ${body}`.slice(0, 40); }
}

// Abstraction: what the message is. It holds the bridge to a Sender.
abstract class Message {
  constructor(protected sender: Sender) {}
  abstract send(to: string): string;
}

class Alert extends Message {
  constructor(sender: Sender, private problem: string) { super(sender); }
  send(to: string): string {
    return this.sender.deliver(to, "ALERT", this.problem.toUpperCase());
  }
}

class Reminder extends Message {
  constructor(sender: Sender, private task: string, private due: string) { super(sender); }
  send(to: string): string {
    return this.sender.deliver(to, "Reminder", `${this.task} by ${this.due}`);
  }
}

console.log(new Alert(new SmsSender(), "disk full").send("+100")); // sms +100 | ALERT: DISK FULL
console.log(new Reminder(new EmailSender(), "Pay invoice", "Friday").send("[email protected]"));
// email [email protected] | Reminder | Pay invoice by Friday

Adding a PushSender is one class, and it immediately works with alerts and reminders. Adding a Digest message is one class, and it immediately works with every sender. Because the sender is just a constructor argument, it can also be chosen at run time, for example from user preferences.

When to use it, and when not to

Use Bridge when:

• A class varies in two or more independent dimensions, and inheritance would create a class for every combination.
• You want to switch the implementation at run time, or share one implementation object among several abstractions.
• You build code that must run on several platforms (operating systems, rendering back ends, database engines) and want the platform details in one separate hierarchy.

Avoid it when:

• There is only one dimension of change. A simple interface with several implementations is enough.
• You are adding it "for later" with only one implementation. The extra layer makes the code harder to read for no benefit yet.

Real-world uses

• JDBC in Java is a well-known example: application code is written against the JDBC API, while each database vendor provides a driver that implements the low-level operations. The two sides evolve independently.
• Graphics and UI toolkits keep a platform-independent widget or shape API on top of platform-specific drawing back ends. The GoF book's own example is a Window abstraction with a separate WindowImp implementation per window system.
• Logging libraries often separate the logger API that code calls from the handlers or appenders that write to files, consoles or network services.

Related patterns