The Bridge Pattern

Key Insight

The Bridge pattern aims to decouple an abstraction from its implementation, allowing both to evolve independently. Traditional inheritance permanently binds an implementation to an abstraction, hindering independent modification, extension, and reuse. For example, creating a portable 'Window' abstraction for both X Window System and IBM's Presentation Manager typically leads to separate 'XWindow' and 'PMWindow' subclasses. If a new window type like 'IconWindow' is introduced, it necessitates creating 'XIconWindow' and 'PMIconWindow', effectively doubling the required classes for each new type or platform. This also makes client code directly dependent on specific platform implementations, complicating portability.

The Bridge pattern resolves this by separating the abstraction (e.g., 'Window', 'IconWindow') and its various implementations (e.g., 'XWindowImp', 'PMWindowImp') into distinct class hierarchies. The 'Abstraction' maintains a reference to an 'Implementor' object, and all operations on the abstraction are defined in terms of the implementor's abstract operations. This creates a 'bridge' between the two, allowing them to vary without impacting each other. This pattern is applicable when a permanent binding between abstraction and implementation must be avoided, enabling run-time selection or switching of implementations. It also supports independent extensibility of both hierarchies, ensures implementation changes do not require client recompilation, and helps hide implementation details from clients.

Key consequences of using the Bridge pattern include improved extensibility, as abstraction and implementor hierarchies can grow independently. It effectively decouples interfaces from implementations, allowing implementations to be configured or changed at run-time and eliminating compile-time dependencies. For instance, ET++'s 'Window' abstraction uses a 'WindowPort' implementor hierarchy, with subclasses such as 'XWindowPort' and 'SunWindowPort', creating a truly portable windowing system. NeXT's AppKit employs an 'NXImage'/'NXImageRep' bridge for image handling, where 'NXImage' dynamically selects the most appropriate 'NXImageRep' implementation (e.g., 'NXEPSImageRep', 'NXBitMapImageRep') based on display capabilities, and can even manage multiple representations simultaneously. In C++, this separation can hide implementation details entirely from clients, sometimes referred to as the 'Cheshire Cat' idiom.