Bridge

The Bridge Pattern is a structural design pattern that lets you split a large class or a set of closely related classes into two separate hierarchies—Abstraction and Implementation—which can be developed independently. By replacing a multi-dimensional inheritance structure with composition, Bridge reduces class growth from a multiplicative Cartesian product to an additive linear scale.

1. Learning Objectives

• Identify Cartesian product class explosion issues in subclass hierarchies.
• Separate domain abstraction interfaces from vendor/platform implementations.
• Evaluate the vtable (virtual method table) execution overhead in dynamic dispatch bridging.
• Compare the intent and structure of Bridge, Adapter, and Strategy patterns.
• Construct decoupled abstraction bridges in Java, Python, and C++ using dynamic composition.

2. Problem & Naive Solution

Imagine you are building a database client application. The client supports:

• Two connection categories: BasicConnection and SecuredConnection (requires encryption).
• Three vendor databases: MySQL, PostgreSQL, and Oracle.

The Naive Solution (Subclass Explosion)

If you model this configuration using traditional inheritance, you must create a subclass for every combination of connection category and database vendor:

• BasicMySQLConnection
• SecuredMySQLConnection
• BasicPostgreSqlConnection
• SecuredPostgreSqlConnection
• BasicOracleConnection
• SecuredOracleConnection

This is a $2 \times 3 = 6$ subclass explosion. If you add a new connection type (ReadOnlyConnection), you must write 3 new subclasses. If you add a new database (MS-SQL), you must write 2 new subclasses. The class count scales multiplicatively ($M \times N$).

3. Issues

This multiplicative class growth creates severe maintenance overhead. Code for executing queries is copied across multiple vendor subclasses, violating the DRY (Don't Repeat Yourself) principle. Changes to the database vendor API require updates across all connection classes, making the system brittle and hard to extend.

4. Pattern Introduction & UML

The Bridge Pattern solves this issue by separating the connection categories (Abstraction) from the database vendors (Implementation). We create a DatabaseConnection abstraction that references a DatabaseDriver interface. The connection logic is written in the abstraction hierarchy, while vendor-specific queries are delegated to the driver. This turns a multiplicative class explosion into a linear relationship ($M + N$).

UML: Database Connection Bridge

5. Participants

• Abstraction (DatabaseConnection): The high-level control interface that references the implementation driver.
• Refined Abstraction (SecuredConnection): Extends the control interface to add features (e.g. payload encryption) without modifying the driver code.
• Implementor (DatabaseDriver): The common interface for all database-specific engines.
• Concrete Implementor (MySQLDriver, PostgreSQLDriver): The actual database-specific socket connections and syntax engines.

6. Theory (Linear Growth vs. Cartesian Product)

The core value of the Bridge pattern is reducing class growth:

• Linear Scaling: If you have $M$ connection types and $N$ database vendors, subclassing requires $M \times N$ classes. A Bridge structure requires only $M + N$ classes.
• Comparison: - Bridge: Used during initial system design to let abstractions and implementations vary independently. - Adapter: Used after a system is written to make incompatible interfaces work together. - Strategy: Focuses on swapping algorithms or behaviors inside a class context.

7. Syntax Explanation

Implementing a Bridge involves binding the implementor reference:

• Java: Declares a protected member variable referencing the DatabaseDriver interface, initialized via the constructor (protected final DatabaseDriver driver;).
• Python: Accepts the driver object dynamically, leveraging duck typing for runtime dispatch.
• C++: Uses std::unique_ptr or std::shared_ptr to store the implementor pointer, preventing memory leaks when deleting the abstraction.

8. Step-by-Step Implementation

1. Step 1: Create the DatabaseDriver implementor interface defining low-level execution methods.
2. Step 2: Build the MySQLDriver and PostgreSQLDriver concrete implementor classes.
3. Step 3: Create the DatabaseConnection base abstraction class, holding a reference to the implementor.
4. Step 4: Build the refined abstraction SecuredConnection class that adds features like encryption.
5. Step 5: Instantiate connections by injecting the appropriate driver implementation (e.g. new SecuredConnection(new MySQLDriver())).

9. Complete Code (Mini Project)

10. Code Walkthrough

Let's review the decoupling architecture:

• Separate Evolution Paths: You can add new connection types (ReadOnlyConnection) in DatabaseConnection without modifying the DatabaseDriver classes. Similarly, you can add support for OracleDriver without altering the connection abstraction.
• Unified Delegation: The abstraction delegates operations (like openConnection() or executeSQL()) to the driver. The client only interacts with the refined connections, keeping the client decoupled from low-level database operations.
• Security Layer Insertion: The refined abstraction SecuredConnection intercepts queries, encrypts the SQL payload, and passes the encrypted string to the driver database engine.

11. Execution Flow

1. Initialization: The application instantiates a concrete implementor (e.g. MySQLDriver) and injects it into a refined abstraction constructor (e.g. SecuredConnection).
2. Client Call: The client calls query("SELECT...") on the connection object.
3. Payload Encryption: The connection encrypts the payload.
4. Driver Delegation: The connection calls executeSQL() on the driver, executing the query.

12. Internal Working (vtable Dispatch Overhead)

Decoupling abstraction from implementation introduces a small runtime dispatch overhead:

• Virtual Table (vtable) Dynamic Dispatch: When the abstraction calls a driver method (e.g. driver.executeSQL()), the compiler cannot resolve the target address at compile-time. It must perform a runtime lookup in the class's Virtual Method Table (vtable) to find the concrete implementation address. This introduces a slight CPU execution delay compared to direct static method binding.
• Heap Pointer Chasing: The abstraction stores a pointer reference to the driver. Resolving calls requires dereferencing the driver pointer, which can cause CPU cache misses if the driver object is not loaded in L1/L2 cache memory.

13. Complexity Analysis

• Time Complexity: $O(1)$ constant overhead to resolve driver vtable dispatch.
• Space Complexity: $O(1)$ constant space overhead to hold reference pointers to the implementor classes.

14. Best Practices

• Keep Implementors Stateless: The implementor drivers should ideally focus on execution and keep state minimal, storing connection parameters within the abstraction connection classes.
• Hide Implementors Behind Factories: Use a Factory pattern to resolve and instantiate drivers based on connection properties, shielding clients from concrete implementation classes.

15. Common Mistakes

• Applying the Pattern Prematurely: Implementing a Bridge when you only have one abstraction and one implementation. The pattern should only be used when hierarchies are expected to grow.
• Confusing Bridge with Adapter: Applying a Bridge to glue legacy code. Bridge is a design-time architectural pattern, whereas Adapter is a post-development wrapping pattern.

16. Framework Usage

• JDBC Database Drivers: The JDBC API is a classic Bridge implementation. The java.sql.Connection and Statement abstractions act as the abstraction layer, bridging to vendor-specific JDBC driver implementations.
• Java AWT Peer Architecture: AWT components (e.g. java.awt.Button) are abstractions that link to platform-specific Peer implementations (e.g., WindowsButtonPeer, MotifButtonPeer) to render components across platforms.

17. Interview Discussion

18. Practice Exercises

• Easy: Write a Bridge in Python representing a Pen abstraction (RedPen, BluePen) linked to a DrawingPaper implementor.
• Medium: Design a NotificationSender (SMS, Email) linked to MessageFormat (HTML, PlainText) implementors.
• Hard: Build an file system representation bridge. Abstractions are FolderViewer and AdminFolderViewer. Implementors are LocalFileSystem and S3RemoteFileSystem.

19. Challenge Problem

Design a Cross-Platform Operating System GUI Thread Executor. The application executes tasks in both UI foreground threads and background worker threads. The GUI executor must run on Windows (using Win32 API messages), macOS (using Cocoa run loops), and Linux (using pthread events). Design this executor as a Bridge. Write a solution in Java, Python, or C++ and test executing multiple background tasks across all three operating system implementations.

20. Summary & Cheat Sheet

• Bridge splits a class structure into Abstraction and Implementation hierarchies.
• Reduces class growth from multiplicative ($M \times N$) to additive ($M + N$).
• The Abstraction class aggregates the Implementor interface as a member variable.
• Dynamic dispatch lookups via vtables introduce a minor runtime overhead.

21. Quiz

22. Next Lesson Preview

In the next lesson, we will explore the Flyweight Pattern. We will learn how to support massive numbers of fine-grained objects efficiently by sharing common state details!