Bridge Design Pattern

Introduction 

 

Hello again. We have been taught the power of inheritance, but if we use more than we are supposed to, then it loses its beauty, and unnecessarily too much use of inheritance is not a good practice in object-oriented design. 

 

To address this problem, we can use a bridge pattern, which prefers composition over inheritance.

The bridge pattern decouples an abstraction from its implementation so that the two can vary independently.

 

Let's look at the example of a company, Apple. Apple makes iPhones & Macbooks. They need both hardware and software to build these devices.

 

Let's see how UML can represent this example.

 

An iPhone needs both hardware & software, and a MacBook needs both hardware & software. We don't have to create any more classes, like iPhoneHardware or iPhoneSoftware because we can inject hardware & software classes to an iPhone or a MacBook dynamically, or if there is a new product say, an iPad.

 

Basically classes that are supposed to increase exponentially with every new product in order to satisfy their needs can be injected through the bridge.

 

 

You see, iPhones & MacBooks need hardware & software to build. However, they are resolving their dependencies through a bridge like a structure. The abstract class Apple HAS-A interface IRequisite which is both hardware & software. This will be provided for our products: iPhone & MacBook.

 

Let's understand the terminology:

1. Abstraction: abstract class Apple: the core of the bridge design pattern and contains a reference to the implementer (IRequisite).
2. Implementer: interface IRequisite: It defines the interface for implementation classes. 
3. Concrete class of abstraction: class iPhone & MacBook: implements the Apple(abstraction) and defines their functionalities.
4. Concrete Implementation: class Hardware & Software:  Implements the above interface IRequisite(implementer) by providing a concrete implementation.

We must get into the code before this gets any more confusing.

 

As usual, let's begin with the interface: IRequisite: this declares product's needs.

 

Method SetFirmwareOrSoftwareVesrion() defines which software or hardware, product suppose to have. Other methods set hardware/software's name & price.

namespace Bridge_Design_Pattern
{
    public interface IRequisite
    {
        string SetFirmwareOrSoftwareVesrion();

        double SetPrice();

        string SetFirmwareOrSoftwareName();
    }
}

Let's have our first concrete class: Hardware. For now, we are only considering one hardware motherboard. 

namespace Bridge_Design_Pattern
{
    public class Hardware : IRequisite
    {
        public string SetFirmwareOrSoftwareName()
        {
            return "MotherBoard FirmWare";
        }

        public string SetFirmwareOrSoftwareVesrion()
        {
            return  "5.0";
        }

        public double SetPrice()
        {
            return  20000;
        }
    }
}

Now our second concrete class: software. Again. we are only setting up IOS info. 

namespace Bridge_Design_Pattern
{
    public class SoftWare : IRequisite
    {

        public double SetPrice()
        {
            return  15000;
        }

        public string SetFirmwareOrSoftwareVesrion()
        {
            return  "IOS production version 13.2";
        }

        public string SetFirmwareOrSoftwareName()
        {
            return  "IOS 13.2";
        }
    }
}

Until now, we have built the right side of our bridge. Now let's make the left side.

 

We need abstraction, which has reference to this hardware & software, plus it must be implemented by our products MacBook & iPhone. It is not necessary to have an abstract class, you could have an interface instead. Just set IRequisite in properties rather than the constructor here.

namespace Bridge_Design_Pattern
{
    public abstract class Apple
    {
        IRequisite RequiredHardware { get; set; }
        IRequisite RequiredSoftware { get; set; }

        public Apple(IRequisite hardware, IRequisite software)
        {
            this.RequiredHardware = hardware;
            this.RequiredSoftware = software;
        }
        public abstract string SetProductName();
        public abstract double SetProductPrice();

        public void SetHardware() {
            System.Console.WriteLine("---------Software Details---------");
            System.Console.WriteLine(" Name: "+RequiredHardware.SetFirmwareOrSoftwareName());
            System.Console.WriteLine(" Version: "+RequiredHardware.SetFirmwareOrSoftwareVesrion());
            System.Console.WriteLine(" Price: "+RequiredHardware.SetPrice());
        }
        public void SetSoftware()
        {
            System.Console.WriteLine("---------Hardware Details---------");
            System.Console.WriteLine(" Name: " + RequiredSoftware.SetFirmwareOrSoftwareName());
            System.Console.WriteLine(" Version: "+RequiredSoftware.SetFirmwareOrSoftwareVesrion());
            System.Console.WriteLine(" Price: " + RequiredSoftware.SetPrice());
        }
    }
}

Let's implement our first product: iPhone: the purpose of a parameterized constructor is to solve dependencies. This is, in fact, the raw material for our bridge. 

namespace Bridge_Design_Pattern
{
    public class iPhone : Apple
    {

        public iPhone(IRequisite hardware, IRequisite software): base(hardware, software)
        {

        }


        public override string SetProductName()
        {
           return "IPhone X";
        }

        public override double SetProductPrice()
        {
            return  110000;
        }
    }
}

Now let's make MacBook:

namespace Bridge_Design_Pattern
{
    public class MacBook : Apple
    {

        public MacBook(IRequisite hardware, IRequisite software) : base(hardware, software)
        {

        }

        public override string SetProductName()
        {
            return  "Apple MacBook Pro";
        }

        public override double SetProductPrice()
        {
            return  170000;
        }
    }
}

At last, our caller. The caller doesn't even need to know from where the hardware or software is coming from. This we have handled through our pattern.

using System;

namespace Bridge_Design_Pattern
{
    class Program
    {
        static void Main(string[] args)
        {
            Apple Iphone = new iPhone(new Hardware(), new SoftWare());
            Console.WriteLine("---- iPhone Details ----");
            Console.WriteLine($" Product: {Iphone.SetProductName()} \n Price: {Iphone.SetProductPrice()}");
            Iphone.SetSoftware();
            Iphone.SetHardware();
            Apple MacBook = new MacBook(new Hardware(), new SoftWare());
            Console.WriteLine(Environment.NewLine + Environment.NewLine +"---- MacBook Pro Details ----");
            Console.WriteLine($" Product: {MacBook.SetProductName()} \n Price: {MacBook.SetProductPrice()}");
            MacBook.SetSoftware();
            MacBook.SetHardware();
        }
    }
}

Beautiful! Let's run our project & see the magic...

 

 

Alright!

 

We have successfully implemented a bridge patten.

 

I sincerely hope you enjoyed this article and that you're inspired to apply what you've learned to your own applications.

 

Thank you, & Happy coding.

 
If you have any doubts, connect with me.

• linkedin