Key Words: Bridge design pattern
Topics at a glance:
- Let us bridge the abstract and the implementation entities
- Let us turn on an incandescent bulb and adjust its brightness
- Let us make a florescent bulb as well.
Bridge design pattern
Bridge is a structural design pattern, that separates the implementation and the abstraction into an orthogonally related two-class systems. One class system defines/represents the abstract entities, while another class system defines/represents the actual implementation entities.
For explaining bridge pattern, I am taking the example of the Bulb and its State that we used in the Bulb Controller application of chapter 19. Could you identify the abstract class system in that application? The abstract class system that I am mentioning about is the State class and its derived classes On_State and Off_State. Why are they abstract? State itself is an abstract concept as I have explained in chapter 19. State object only knows to change from one sate to another and manipulate the behavior in each state. They do not really know how to implement the actual functionality that the machine has to perform in that state. For example, how a State class’s object instance will know how to turn on an electric bulb or how to turn off? It does not really.
We will come back to this example later in tis chapter. For citing another example for abstract class systems, consider Process and Thread in any platform.The actual implementation of “processes” and”threads” is platform dependent. Say, one can use C++ threads or posix threads in a program. But if the application/client code to an abstract base class with interfaces to create, run, join, and interact with the thread, what matters whether it’s a posix thread or C++ standard library thread implementation? Coming to process now. A process is defined/implemented by the underlying platform such as Widows, Linux, IOS operating systems or some virtual machine hypervisor. The client only programs to an abstract base class Process. It needs interfaces to create, fork, manage and to kill a process. That’s all the client bothers about.
In normal course, if we are writing a code to only one specific implementation, then no need to have separate abstract class system and implementation class system in your design. But if you want to write a (semi-) portable application that should run regardless of the underlying platform/implementation, then it is imperative that you must program to abstract class systems. Now, the focus comes to this; How you are going to define this abstract class system? Usually through inheritance. We define an abstract base class, and derive concrete classes that are specific to the platform – say Windows, Linux, Posix or C++ standard library. But what if we introduce another platform in future, say, a virtual hypervisor or a simple bare-metal system with a minimal layer supporting process/threads. We cannot continue to inherit which will lead to inheritance misuse as we saw in case of the Page class that I used as an example in chapter 16 – for understanding the need for decorator design pattern. But here, we cannot resort to decorator pattern, as we need a way to abstract the implementation and our purpose is not to add features/functionalities on top of a base class. We will need a way to separate the abstract class system from the implementation class system. This is where bridge pattern comes in for help.
Bridge pattern separates the abstract class system that define abstract entities from actual implementation class system that is platform dependent. Let us come back to our light control application. Here, user need a feature to add support for incandescent bulbs that supports dimming/adjusting the brightness and for fluorescent bulb technology that gives more light for lesser power.
Turning on, off, changing the brightness cannot be defined in the abstract Bulb class or in the abstract State class. We need another implementation specific class system called the Light_Device class and its concrete derived classes that implements the functionality to support incandescent and fluorescent technologies.
Now, Bulb class will also contain a pointer reference to the Light_Device object instance in addition to the State instance. But, Bulb, as before, delegates the state manipulation to its State object and State object after managing the state, delegates the task for turning on or turning off the light bulb to the Light_Device object instance that the Bulb object possess. Bulb class also have to define one interface to get the Light_Device object instance for delegating these tasks to turn on, off and change brightness to Light_Device object through State object.
Now, let us see the bridge pattern in action.
Want to see the result?
Bulb controller application Enter the bulb technology required : (I) : Incandescent (F) : Fluorescent I What to do next : ON, OFF, SET_BRIGHTNESS, EXIT ON Incandescent bulb turned on What to do next : ON, OFF, SET_BRIGHTNESS, EXIT SET_BRIGHTNESS Enter the required brightness level 50 Brightness set at 50 What to do next : ON, OFF, SET_BRIGHTNESS, EXIT OFF Incandescent bulb turned off What to do next : ON, OFF, SET_BRIGHTNESS, EXIT EXIT Exiting bulb controller application
Incandescent bulb support changing the brightness. Now let us see what happens when the user chooses to create a fluorescent bulb instead.
Bulb controller application Enter the bulb technology required : (I) : Incandescent (F) : Fluorescent F What to do next : ON, OFF, SET_BRIGHTNESS, EXIT ON Fluorescent bulb turned on What to do next : ON, OFF, SET_BRIGHTNESS, EXIT SET_BRIGHTNESS This operation not supported for fluorescent device What to do next : ON, OFF, SET_BRIGHTNESS, EXIT OFF Fluorescent bulb turned off What to do next : ON, OFF, SET_BRIGHTNESS, EXIT EXIT Exiting bulb controller application
See the difference now? Both the Bulb and State classes does not really bother about the implementation. They just delegate the task that depends upon the implementation to the relevant implementation object. i.e. Light_Device instance. That’s the advantage of bridge pattern.
Enjoyed the chapter? Let me know in the comments below. Thanks 😊