Table of Contents
What is the Bridge Pattern?
The definition of the Bridge Pattern from both Design Patterns: Elements of Reusable Object-Oriented Software
The Bridge Pattern allows you to vary the implementation and the abstraction by placing the two in separate class hierarchies.
Bridge Pattern Pattern Class Diagram Explained
Bridge Pattern Class Diagram
Looking at the class diagram, you can see that there is an Abstraction abstract class with RefinedAbstraction as a subclass. The Abstraction class has an Implementor interface implemented by two classes, ConcreteImplementorA and ConcreteImplementorB. So instead of the implementations being subclasses of the Abstraction class, it is separated from the Abstraction class hierarchy and placed into its own (i.e. Implementor and its implementations).
Benefits of the Bridge Pattern
There are a few benefits when using the Bridge Pattern. First, The abstraction and the implementation are decoupled. This adds the benefit of configuring and/or changing the implementation at runtime. In addition, the decoupling allows the client and the abstraction to only depend on interface to the implementations, not the implementations themselves. So changing the implementations doesn’t force the client and abstraction to recompile.
Another benefit to using the Bridge Pattern is that its easier to extend the abstraction and the interface to the implementations since they are separate.
Finally, the details of the implementation are hidden from the client.
Bridge Pattern Example using C++
To demonstrate the Bridge Pattern, I decided to write a little program to show how different variants of a cell phone text application can use a service provider variant to implement select features. And why not use the most popular phones on the market today, the Samsung Galaxy S8 and Apple’s IPhone 8 and the most popular cell phone service providers in Verizon and Sprint.
Let’s begin with an abstract class CellPhoneTextApp as our Abstraction class with two RefinedAbstraction subclasses, GalaxyS8TextApp and IPhone8TextApp. Each would implement the abstract methods, Open() and Close() of their parent class for opening and closing the application, respectively. The behavior for sending a text would be delegated to an Implementor interface, CellPhoneTextAppImpl. Implementations of this interface, VerizonPhoneTextAppImpl and SprintPhoneTextAppImpl would vary based on service providers, Verizon and Sprint, respectively. In this example, these concrete implementors are responsible for defining the behavior of sending a text via SendTextImpl(). The relationship between the CellPhoneTextApp and the CellPhoneTextAppImpl is the bridge part of the pattern.
So we have our design finished. Let’s take a look and see what our implementation will look like.
CellPhoneTextAppImpl.h
SprintPhoneTextAppImpl.h
SprintPhoneTextAppImpl.cpp
VerizonPhoneTextAppImpl.h
VerizonPhoneTextAppImpl.cpp
CellPhoneTextApp.h
CellPhoneTextApp.cpp
GalaxyS8TextApp.h
GalaxyS8TextApp.cpp
IPhone8TextApp.h
IPhone8TextApp.cpp
CellPhoneTextAppTest.cpp
Here is the output of the program.
Opening Galaxy S8 Text App.
Sending message…
“Can you hear me now?”
To recipients :
555-123-4567
555-765-4321
over Sprint network
Closing Galaxy S8 Text App.
Opening IPhone 8 Text App.
Sending message…
“Can you hear me now?”
To recipients :
555-123-4567
555-765-4321
over Verizon network
Closing IPhone 8 Text App.
Recommended Resources
Here are some resources I recommend for more information on the Bridge Pattern
Head First Design Patterns: A Brain-Friendly Guide
Design Patterns: Elements of Reusable Object-Oriented Software
In Closing
There you have it. If you followed along, I hope you now have a better understanding of the Bridge Pattern. Please feel free to leave comments and feedback. Much appreciated!