Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Decouple an abstraction from its implementation so that the two can vary independently." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
When an abstraction can have one of several possible implementations, the usual way to accommodate them is to use inheritance. An abstract class defines the interface to the abstraction, and concrete subclasses implement it in different ways. But this approach isnt always flexible enough. Inheritance binds an implementation to the abstraction permanently, which makes it difficult to modify, extend, and reuse abstractions and implementations independently. Consider the implementation of a portable Window abstraction in a user interface toolkit. This abstraction should enable us to write applications that work on both the X Window System and IBMs Presentation Manager (PM), for example. The Bridge pattern puts the Window abstraction and its implementation in separate class hierarchies. There is one class hierarchy for window interfaces (Window, IconWindow, ApplicationWindow) and a separate hierarchy for platform-specific window implementations, with WindowImp as its root. The XWindowImp subclass, for example, provides an implementation based on the X Window System. All operations on Window subclasses are implemented in terms of abstract operations from the WindowImp interface. This decouples the window abstractions from the various platform-specific implementations. We refer to the relationship between Window and WindowImp as a bridge, because it bridges the abstraction and its implementation, letting them vary independently
This pattern has been used on the following systems: Libg++ defines classes that implement common data structures. Some structures are Set (abstract class that defines a set abstraction), LinkedList (concrete implementor for a linked list), and HashTable (concrete implementor for a hash table). LinkedSet and HashSet are Set implementors that bridge between Set and their concrete counterparts LinkedList and HastTable. This is an example of a degenerate bridge, because theres no abstract Implementor class. (Lea, D., the GNU C++ library. In Proceedings of the 1988 USENIX C++ Conference, pp. 243-256, Denver, CO, October 1988. USENIX Association.) NeXTs AppKit uses the Bridge pattern to implement and display graphical images. An image can be represented in different ways; however, the properties of a display device (color, resolution, etc.) control the optimal display of the image. AppKit provides a NXImage/NXImageRep bridge so developers do not have to determine which implementation to use under various circumstances. ( Addison-Wesley, Reading, MA. NEXTSTEP General Reference: Release 3, Volumes 1 and 2, 1994.)
Abstract Factory and Adapter patterns
Abstract Factory pattern, Adapter pattern, Bridge pattern, structural patterns, Gamma patterns, Adapter Class pattern, Adapter Object pattern, Handle/Body pattern, forward requests, decouple abstraction and implementation
any system with high probability of change that needs to be encapsulated from clients
need a class that is reusable in multiple, unforeseen contextsneed to de-couple a class and its implementation
enhanced maintainability and extensibility of the systemincreases reuse of classes by de-coupling the interface from the implementationpromotes layering of systems
Test driver Test.javaSimple implementation of the pattern - RefinedAbstraction class. RefinedAbstraction.javaSimple implementation of the pattern - Implementor class. Implementor.javaSimple implementation of the pattern - ConcreteImplementorB class. ConcreteImplementorB.javaSimple implementation of the pattern - ConcreteImplementorA class. ConcreteImplementorA.javaSimple implementation of the pattern - Abstraction class. Abstraction.javaTest driver testbridge.cppSimple implementation of the pattern. bridge.h