Bridge Design Pattern
It decouples a set of implementations from the set of objects using them.
Figure 1: Diagram class of Drawing program without Bridge design pattern
Unfortunately, this solution suffers from combinatorial explosion because of tight coupling. Imagine that we need to add a third version of drawing program (DP3). Then we will have six different shapes (V1Rectangle, V2Rectangle, V3Rectangle, V1Circle, V2Circle, V3Circle)
This problem arises because the abstraction (Shape) and the implementation (Drawing) are tightly coupled. We have to decouple the abstraction and the implementation to make it easier to modify, extend, and reuse abstractions and implementations independently which are the motivation of Bridge design pattern.
Figure 2: Diagram class of Drawing program with Bridge design pattern
Note: Handling a new implementation is very easy with a Bridge pattern; we must only add a new Drawing implementation "V3Drawing". Still this solution is not perfect because when we add a new Shape implementation (ellipse), we must also add the corresponding drawing functions to the Ellipse. However, the bridge pattern localize the impact of modification and decreases the risk of errors.
Note also that the solution presented in Figures 2 integrates the Adapter pattern with the Bridge pattern.
When we use the bridge design pattern:
- You want to avoid a permanent binding between an abstraction and its implementation.
- Changes in the implementation of an abstraction should have no impact on clients. The abstraction contains a reference to the implementor.
- The decoupling of the implementations from the objects that use them increases extensibility.
- Client objects are not aware of implementation issues.
Ralph Johnson; Richard Helm; Erich Gamma; John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software.Addison-Wesley Professional, 1994