2.2 Bridge

The Bridge pattern handles a classic design pressure: one thing varies along two independent dimensions at once. A notification system has "message type" (welcome, receipt, security alert) and "delivery channel" (email, SMS, push); a remote has "remote type" and "controlled device."

If you express both dimensions through inheritance, the class count explodes as M×N: WelcomeEmail, WelcomeSms, ReceiptEmail, ReceiptSms… Bridge's idea is to split the two dimensions into independent families and connect them with composition (a "bridge"), so adding a new message type or channel does not require rewriting every pair.

The notification bridge lab below lets you add message types and delivery channels, then watch how the mixed-together design creates paired classes. Turn on Bridge to see message types and senders maintained separately.

Abstraction and implementation, evolving separately

In Bridge terminology, the two dimensions have dedicated names:

• Abstraction: the high-level, client-facing part, e.g., the "remote."

• Implementor: the low-level capability, e.g., the "device."

abstract class Remote {
    protected Device device;          // this is the "bridge": composition, not inheritance
    Remote(Device device) { this.device = device; }
    abstract void togglePower();
}

class BasicRemote extends Remote {
    BasicRemote(Device d) { super(d); }
    void togglePower() { device.setPower(!device.isOn()); }
}

Notice that Remote holds a Device reference — that one line is the bridge. The remote hierarchy and the device hierarchy can each add subclasses without disturbing the other. The lab below lets you mix and match remotes and devices and operate them.

Bridge vs Adapter: different intent

Both use composition, and beginners confuse them — but their intent is opposite: