The Bridge pattern addresses the problem of exploding class hierarchies by decoupling an abstraction from its implementation. Instead of binding these two dimensions together at compile time, the pattern introduces a composition relationship that allows both sides to evolve independently. This structural approach is particularly useful when dealing with multiple orthogonal variations, such as different message formats paired with various delivery mechanisms.

A standard Bridge implementation consists of four primary roles:

• Abstraction: Defines the high-level control interface and maintains a reference to an implementor object.
• Refined Abstraction: Extends the abstraction interface with specific business logic.
• Implementor: Declares the low-level operations that concrete implementations must fulfill.
• Concrete Implementor: Provides platform-specific or variant-specific behavior for the implementor interface.

The following Python implementation demonstrates this separation using a notification system. The abstraction handles message formatting, while the implementor manages the actual transmission protoclo.

from abc import ABC, abstractmethod

# Implementor Interface
class DeliveryChannel(ABC):
    @abstractmethod
    def transmit(self, payload: str) -> None:
        pass

# Concrete Implementors
class EmailGateway(DeliveryChannel):
    def transmit(self, payload: str) -> None:
        print(f"[EMAIL] Routing payload: {payload}")

class PushNotificationService(DeliveryChannel):
    def transmit(self, payload: str) -> None:
        print(f"[PUSH] Dispatching to mobile devices: {payload}")

# Abstraction
class MessageDispatcher:
    def __init__(self, channel: DeliveryChannel):
        self._channel = channel

    def publish(self, content: str) -> None:
        self._channel.transmit(content)

# Refined Abstractions
class CriticalAlert(MessageDispatcher):
    def publish(self, content: str) -> None:
        formatted = f"⚠️ CRITICAL: {content.upper()}"
        super().publish(formatted)

class DailyDigest(MessageDispatcher):
    def publish(self, content: str) -> None:
        formatted = f"📅 Daily Summary: {content.title()}"
        super().publish(formatted)

The composition occurs at runtime, enabling dynamic pairing of message types with delivery mechanisms without modifying existing classes:

# Instantiate channels
email_route = EmailGateway()
push_route = PushNotificationService()

# Bridge abstractions with implementations
alert_via_email = CriticalAlert(email_route)
digest_via_push = DailyDigest(push_route)

alert_via_email.publish("server overload detected")
digest_via_push.publish("system metrics and uptime report")

By injecting the DeliveryChannel into MessageDispatcher, the system avoids creating a separate class for every possible combination (e.g., CriticalAlertEmail, CriticalAlertPush, DailyDigestEmail). Adding a new channel like SlackIntegration or a new message type like MarketingPromo requires only a single new class that adheres to the respective interface.

classDiagram
    class MessageDispatcher {
        +DeliveryChannel _channel
        +publish(content)
    }
    class CriticalAlert {
        +publish(content)
    }
    class DailyDigest {
        +publish(content)
    }
    class DeliveryChannel {
        <<interface>>
        +transmit(payload)
    }
    class EmailGateway {
        +transmit(payload)
    }
    class PushNotificationService {
        +transmit(payload)
    }

    MessageDispatcher <|-- CriticalAlert
    MessageDispatcher <|-- DailyDigest
    MessageDispatcher o-- DeliveryChannel
    DeliveryChannel <|.. EmailGateway
    DeliveryChannel <|.. PushNotificationService

The structural separation ensures that modifications to the transmission logic remain isolated from the message formatting rules. This boundary enforcement reduces regression risks and streamlines unit testing, as each hierarchy can be validated with mock counterparts.