Bridge design pattern for beginners.

Problem statement –

You have got into a situation, where you need to add, or maybe remove, a new feature in the existing software system. But you have no permission to modify the current concrete implementation. How you will address that problem? Also, can we refine our interfaces for different requirements? 

Background –

As standard, we expose abstract layer to the client. The client calls to those APIs without bothering how it is implemented in your library. The library is a black box for clients. Whatever we add or remove any functionality, we have to maintain our interface in such a way, the client code shall not break.

To achieve that, we can create layers of abstraction (interfaces) and separate the concrete implementation from the abstract layer. Not all interfaces need to expose the same APIs.

For example, company A is using some payment gateway called X in the online e-commerce portal's transactions. But as payment gateway, Y becomes more secure, famous, and less costly. I want my new modules to use new payment gateway Y, and the old legacy module shall continue to use gateway X. But gateway Y comes with the new API set, which partially fits in our existing gateway interface. How you will integrate it? 

We can add a refined interface to implement Y payment gateway module. Bridge design pattern will solve my problem. You will understand more in below section. 

About bridge design pattern –

Through this design pattern, we can create, refined interfaces (abstractions) and add new features without affecting the existing one.

It separates implementation and abstraction. Many design does that, but it separates the full hierarchy of implementations from the abstract layer. We add even further abstractions and create a hierarchy of new feature implementation. You will see it through UML blog diagram and example.

Bridge is actually a bridge between client interface and actual implementation interfaces.

What is the difference between bridge and strategy design pattern –

We use strategy when we want to swap between strategies based on user's input at run time. Bridge is more on structural implementation of two or more than two, similar but different objects.

Strategy is run time strategy. To pick a different algorithm, like when you take an interview, you see resume, years of experience, skillset, and then decide what questions to be asked. Bridge use to select what interface you want to choose to complete your task.

What is the difference between bridge and adapter design pattern –

According to GoF – “Adapter makes things work after they're designed; Bridge makes them work before they are.”

What is the difference between bridge and decorator design pattern –

In decorator, you maintain the same interface in decorator class, as it is in the actual interface. The client feels as if he is using actual interface. There is no such constraints in the bridge.

Structure –

Example - 

#include <iostream>
using namespace std;
class MobileGUIImpl
{
    public:
        virtual void welcomeDisplay() = 0;
};

class AppleMobileGUIImpl : public MobileGUIImpl
{
    public:
        void welcomeDisplay()
        {
            cout<< "hello user welcome to Apple mobile " << endl;
        }
};

class AndroidMobileGUIImpl : public MobileGUIImpl
{
    public:
        void welcomeDisplay()
        {
            cout<< "hello user welcome to Android mobile " << endl;
        }
};

class WindowsMobileGUIImpl : public MobileGUIImpl
{
    public:
        void welcomeDisplay()
        {
            cout<< "hello user welcome to Windows mobile " << endl;
        }
};

class MobileGUI
{
    public:
        MobileGUI() {}
        MobileGUI(MobileGUIImpl* mobileGUIImpl): m_mobileGUIImpl(mobileGUIImpl) {}
        virtual void welcomeDisplay()
        {
            m_mobileGUIImpl->welcomeDisplay();
        }
    protected:
        MobileGUIImpl* m_mobileGUIImpl;
};

class AppleMobileGUI : public MobileGUI
{
    public:
        AppleMobileGUI()
        {
            m_mobileGUIImpl = new AppleMobileGUIImpl;
        }
        void welcomeDisplay()
        {
            MobileGUI::welcomeDisplay();
        }
};

class AndroidMobileGUI : public MobileGUI
{
    public:
        AndroidMobileGUI()
        {
            m_mobileGUIImpl = new AndroidMobileGUIImpl;
        }
        void welcomeDisplay()
        {
            MobileGUI::welcomeDisplay();
        }    
};

class WindowsMobileGUI : public MobileGUI
{
    public:
        WindowsMobileGUI()
        {
            m_mobileGUIImpl = new WindowsMobileGUIImpl;
        }
        void welcomeDisplay()
        {
            MobileGUI::welcomeDisplay();
        }    
};

/*
#######################################################################################
#########  __  __       _        ######################################################
######### |  \/  | __ _(_)_ __   ######################################################
######### | |\/| |/ _` | | '_ \  ######################################################
######### | |  | | (_| | | | | | ######################################################
######### |_|  |_|\__,_|_|_| |_| ######################################################
#######################################################################################
*/
int main( int argc, char** argv)
{
    MobileGUI* win = new WindowsMobileGUI;
    MobileGUI* apple = new AppleMobileGUI;
    MobileGUI* android = new AndroidMobileGUI;
    
    win->welcomeDisplay();
    apple->welcomeDisplay();
    android->welcomeDisplay();
    return 0;
}

Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.