Design Pattern For Beginner Part 7: Bridge Design Pattern

Welcome to the Design Pattern For Beginner article series. In this article we will try to understand the Bridge Design Pattern. If this article is your first article in this series then I suggest you visit the other articles in this series.

• Design Pattern For Beginners - Part 1: Singleton Design Pattern
• Design Pattern For Beginners - Part 2: Factory Design Pattern
• Design Pattern For Beginners - Part 3: Prototype Design Pattern
• Design Pattern For Beginners - Part 4: Decorator Design Pattern
• Design Pattern For Beginners - Part 5: Composite Design Pattern
• Design Pattern For Beginners - Part 6: Adaptor Design Pattern
• Design Pattern For Beginners - Part 7: Bridge Design Pattern
• Design Pattern For Beginners - Part 8: memento Design Pattern
• Design Pattern for Beginners - Part-9: Strategy Design Pattern
• Design Pattern for Beginners - Part-10: Observer Design Pattern
• Design Pattern For Beginners - Part 11: Implement Decouple Classes in Application
  

Why Bridge Pattern?

Before starting with a technical explanation and example we will try to understand why the Bridge Design Pattern is essential and in which scenario it will be implemented.

As the name suggests, it makes a bridge between two components. Here the component may be two classes or any other entity. So the Bridge Design Pattern basically makes a channel between two components. And in this way it helps to create a de-couple architecture. We can communicate with two classes through the bridge component without changing existing class definitions.

So if we summarize the basic need for the Bridge Design Pattern then we will see that it help us to design a de-couple architecture in the software project. It makes abstraction over implementation.

Let's implement the first example

In the following we implement one small example of the Bridge Design Pattern. When we are talking of bridge let's implement a simple bridge between two cities. Here instead of city we will call it node.

In the example we have implemented an Inode interface in both the Node_A and Node_B class. Then in the following, the two node classes, we have defined another class called Bridge, that will communicate between two cities. The ReachTo() function of the bridge class will take us to a specific city (node). Now we are clearly seeing the Program class (Main() function) is talking with any city class (node) through the Bridge class.

using System;
using System.Collections;
namespace BridgeDesign
{
    public interface Inode
    {
        void Reach();
    }
    class Node_A : Inode
    {
        public void Reach()
        {
            Console.WriteLine("Rreached to node A");
        }
    }
    class Node_B : Inode
    {
        public void Reach()
        {
            Console.WriteLine("Rreached to node B");
        }
    }
    class Bridge
    {
        public void ReachTo(Inode obj)
        {
            obj.Reach();
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            Bridge br = new Bridge();
            Node_A a = new Node_A();
            Node_B b = new Node_B();
            br.ReachTo(a); //Reach to Node_A
            br.ReachTo(b); //Reach to Node_B
            Console.ReadLine();
        }
    }
}

Here is sample output.

Hmm.. What an unrealistic example. Yes this example is only for you to understand the basic implementation of the Bridge Design Pattern. OK, let's work with one useful example (at least related to realistic project development).

The Mail sending operation was implemented by a Bridge Pattern.

Mail sending and notification is a very common task for a software developer. We can now send mail in various ways, for example in a new version of an old project you have developed a mail sending function in C# but in the same project there is another function to send mail that is written in VB6 (maybe it was written by a senior of your seniors. Ha ..Ha..) and is still working fine.

Anyway, your manager said that they want to use both C# and VB versions associated with sending mail from a database (so, in total three different ways). Now, let's implement this scenario using the Bridge Design Pattern. Have a look at the following example.

using System;
using System.Collections;
namespace BridgeDesign
{
    public interface IMessage
    {
        void Send();
    }
    class CSharp_Mail : IMessage
    {
        public void Send()
        {
            Console.WriteLine("Mail send from C# code");
        }
    }
    class VB_Mail : IMessage
    {
        public void Send()
        {
            Console.WriteLine("Mail send from VB Code");
        }
    }
    class Databas_Mail : IMessage
    {
        public void Send()
        {
            Console.WriteLine("Mail send from Database");
        }
    }
    class MailSendBridge
    {
        public void SendFrom(IMessage obj)
        {
            obj.Send();
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            MailSendBridge mb = new MailSendBridge();
            CSharp_Mail objCS = new CSharp_Mail();
            VB_Mail objVB = new VB_Mail();
            mb.SendFrom(objCS);    //Mail send from C# cod
            mb.SendFrom(objVB);  //Mail Send from VB Code
            Console.ReadLine();
        }
    }
}

If you observe closely the body of the Main() function, you will find we are sending just an appropriate object to use the proper mail sending function. Here the MailSendBridge class is creating one abstraction over the implementation of the actual mail sending mechanism that was defined by a different mail sending class.

Here is sample output.



Conclusion

Here we were trying to understand the Bridge Design Pattern with examples. IU hope you have understood the basic concept and implementation of the Bridge Design Pattern.