Bridge: split abstraction from implementation

Bridge splits a class hierarchy that grows in two directions into two hierarchies joined by composition. One side, the abstraction, is what clients use: here, the kinds of message an application sends, such as alerts, reminders and receipts. The other side, the implementation, is how the work gets done: delivery channels such as email, text messages and chat. Each message holds a channel object and calls it, so a new channel or a new kind of message is one new class, and the two sides vary independently, even while the program runs. Bridge is a design decision made up front, when you can see both directions of change coming; Adapter makes an existing interface fit after the fact.

Python 3.14.8, Node.js 24.21.0 and Apple clang 21.0.0 ran the programs below, and most of the Python and JavaScript ones can be run again in your browser.

The class explosion: three kinds times three channels

A natural first design gives each combination its own subclass: AlertEmail, AlertSms, AlertChat, ReminderEmail and so on, nine classes for three kinds and three channels. Each class repeats the formatting of its channel, so the rule for a text message lives in three places. The count grows as a product: a fourth channel adds three classes, a fourth kind after it adds four, and five kinds over four channels need 20. In general, n kinds and m channels need n × m subclasses.

Bridge turns the product into a sum. The kinds of message form one hierarchy and the channels another, and the base class of the kinds holds a reference to a channel. That reference is the bridge:

Bridge in code

Message is the abstraction. Its send() asks its channel to deliver the message’s title and body, and each kind supplies only those two parts. Channel is the implementation side, and each channel formats a delivery its own way:

"""Three kinds of message times three delivery channels, as a Bridge: 3 + 3 classes instead of 3 x 3 subclasses."""

from abc import ABC, abstractmethod


class Channel(ABC):
    """The implementation side: how a message reaches someone."""

    @abstractmethod
    def deliver(self, to: str, title: str, body: str) -> str: ...


class Email(Channel):
    def deliver(self, to, title, body):
        return f"email to {to}: subject {title!r}, {body}"


class Sms(Channel):
    def deliver(self, to, title, body):
        return f"sms to {to}: {title}: {body}"


class Chat(Channel):
    def deliver(self, to, title, body):
        return f"chat to {to}: *{title}* {body}"


class Message(ABC):
    """The abstraction side: what is said. It holds a channel and does not know which one."""

    def __init__(self, channel: Channel) -> None:
        self.channel = channel

    def send(self, to: str) -> str:
        return self.channel.deliver(to, self.title(), self.body())

    @abstractmethod
    def title(self) -> str: ...

    @abstractmethod
    def body(self) -> str: ...


class Alert(Message):
    def __init__(self, channel: Channel, problem: str) -> None:
        super().__init__(channel)
        self.problem = problem

    def title(self):
        return "Alert"

    def body(self):
        return self.problem


class Reminder(Message):
    def __init__(self, channel: Channel, event: str, at: str) -> None:
        super().__init__(channel)
        self.event, self.at = event, at

    def title(self):
        return "Reminder"

    def body(self):
        return f"{self.event} at {self.at}"


class Receipt(Message):
    def __init__(self, channel: Channel, order: int) -> None:
        super().__init__(channel)
        self.order = order

    def title(self):
        return "Receipt"

    def body(self):
        return f"order {self.order} is paid"


for channel in (Email(), Sms(), Chat()):
    for message in (Alert(channel, "disk 91% full"), Reminder(channel, "stand-up", "09:30"), Receipt(channel, 1042)):
        print(message.send("asha"))

kinds, channels = len(Message.__subclasses__()), len(Channel.__subclasses__())
print(f"classes: {kinds} kinds + {channels} channels = {kinds + channels}; a subclass per pair would be {kinds * channels}")

reminder = Reminder(Email(), "stand-up", "09:30")
reminder.channel = Sms()  # the implementation changes while the program runs
print(reminder.send("asha"))

email to asha: subject 'Alert', disk 91% full
email to asha: subject 'Reminder', stand-up at 09:30
email to asha: subject 'Receipt', order 1042 is paid
sms to asha: Alert: disk 91% full
sms to asha: Reminder: stand-up at 09:30
sms to asha: Receipt: order 1042 is paid
chat to asha: *Alert* disk 91% full
chat to asha: *Reminder* stand-up at 09:30
chat to asha: *Receipt* order 1042 is paid
classes: 3 kinds + 3 channels = 6; a subclass per pair would be 9
sms to asha: Reminder: stand-up at 09:30

The nine lines are every pairing of kind and channel, and they come from six classes, counted by the program from its own class hierarchy. The last line is the same reminder sent again after its channel was replaced, without a new object or a new class. That is the intent of the pattern: the abstraction and the implementation vary independently. With n kinds and m channels, a Bridge needs n + m classes instead of n × m, so five kinds over four channels need 9 classes instead of 20.

When a Bridge is worth it

Reach for a Bridge when you can name two independent directions of change before you write the classes, and both will grow: kinds of message and channels, shapes and renderers, reports and output formats, devices and their remote controls. If only one side will ever vary, a plain interface is enough. If the second side has one member and no second one is in sight, the extra layer is overhead you pay for nothing. The running cost of a Bridge is small: one more object per message and one more call per operation. The real work is designing the implementation’s interface, because every kind of message must be expressible through it.

Bridge and the patterns that look like it

Several patterns share the shape of an object that holds another object and delegates to it. What tells them apart is intent:

• Adapter makes an existing interface fit another one after both exist; a Bridge is planned before either side is written.
• Strategy swaps one algorithm inside an object, such as a sort order; a Bridge implementation is a whole platform or back end with several operations.
• Pimpl, a C++ idiom, is a Bridge with a single implementation: the header holds only a pointer, so the private members can change without recompiling the code that uses the class.

Designing the implementation side: primitives, room and switching Pro: opens with a Pro, Premium or Ultimate pass

Pimpl in C++: a Bridge with one implementation, measured on a build Pro: opens with a Pro, Premium or Ultimate pass

Bridge, Adapter or Strategy: telling them apart by change requests Pro: opens with a Pro, Premium or Ultimate pass

Interview questions

Key takeaways

• Bridge splits a hierarchy that grows in two directions into an abstraction and an implementation, joined by a reference from one to the other.
• n kinds and m implementations cost n + m classes with a Bridge, and n × m with a subclass for every pair.
• The abstraction holds its implementation in a field, so the implementation can be replaced while the program runs.
• Bridge is planned up front, Adapter fits existing interfaces together, and Strategy varies one algorithm.