Bridge Design Pattern

Bridge design pattern:

According to the Gang of Four, the intent of the Bridge pattern is to “decouple an abstraction from its implementation so that the two can vary independently. It is Also know as a Handle/Body pattern. It is a structural design pattern.

It decouples a set of implementations from the set of objects using them.

Why Bridge design pattern?

At first, let's check a class diagram of an example without bridge pattern. The program draws Rectangle and Circle with two versions of programs DP1 and DP2.

Usually, we use inheritance when we have several implementations of an abstraction. In this example, we have the abstract class Shape implemented by two classes Rectangle and Circle. Each class implements the needed method (drawLine or drawCircle) and derives a version DP1 and version DP2 for both Rectangle and Circle.

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. Bridgedp2 2

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.

Consequences: