Bridge Pattern
The Bridge Pattern is a structural design pattern that decouples an abstraction from its implementation so the two can vary and evolve independently, by giving the abstraction a reference to a separate implementation interface rather than…
Definition
The Bridge Pattern is a structural design pattern that decouples an abstraction from its implementation so the two can vary and evolve independently, by giving the abstraction a reference to a separate implementation interface rather than inheriting from a concrete implementation.
Overview
The Bridge Pattern addresses a specific failure mode of inheritance: when a class hierarchy needs to vary along two independent dimensions — say, a shape's type (circle, square) and its rendering technology (vector, raster) — naive subclassing produces a combinatorial explosion of classes (VectorCircle, RasterCircle, VectorSquare, RasterSquare, and so on for every new shape or rendering technology added). The Bridge Pattern solves this by splitting the hierarchy in two: an abstraction hierarchy (Shape, Circle, Square) that defines the high-level interface clients use, and a separate implementor hierarchy (Renderer, VectorRenderer, RasterRenderer) that defines the low-level platform-specific operations. The abstraction holds a reference (the "bridge") to an implementor object and delegates the actual work to it, so any abstraction can be paired with any implementor at runtime, and each hierarchy can grow independently without multiplying the other. A well-known real-world application is cross-platform GUI toolkits, where a high-level Window or Button abstraction needs to render correctly on Windows, macOS, and Linux; rather than creating WindowsButton, MacButton, and LinuxButton subclasses for every widget type, the toolkit defines a platform-agnostic widget abstraction bridged to a separate platform-specific implementor that handles the actual native rendering calls. JDBC drivers follow a similar structure, separating the abstract database API that application code uses from the vendor-specific driver implementation that talks to a particular database engine. Bridge is frequently confused with Adapter because both involve one class delegating to another through an interface, but their intents differ: Adapter is applied after the fact to make two incompatible existing interfaces work together, while Bridge is a proactive design decision made up front to keep an abstraction and its implementation independently extensible. Because Bridge requires anticipating the need for independent variation before it happens, it's typically applied when a system is expected to support multiple platforms, backends, or rendering strategies from the start, rather than retrofitted onto an already-tangled hierarchy.
Key Concepts
- Splits a class hierarchy into an abstraction hierarchy and an implementor hierarchy
- Abstraction holds a reference to an implementor object (the 'bridge')
- Avoids combinatorial class explosion from multi-dimensional inheritance
- Abstraction and implementation can vary and be extended independently
- Implementor can typically be swapped at runtime
- Common in cross-platform GUI toolkits and database driver architectures (e.g., JDBC)
- Distinct from Adapter: Bridge is a proactive design, Adapter is a retrofit
- Best applied when multiple platforms/backends are anticipated up front