Design Patterns — A quick guide to Bridge pattern.

5 min readJan 15, 2019

The Bridge pattern is a very important design pattern. It is commonly used in industry as it is an easy way to simplify classes by separating the low-level logic implementation from the high-level definition of a class (which is usually abstracted/inherited). The purpose of this guide is to explain this pattern in three easy, clean steps.

The Bridge pattern is classified among structural design patterns which are all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality. [by Design Patterns explained simply]

Step 1 — Keywords

The formal definition of the Gang of Four (GoF) book — the first people to introduce the design patterns: “Bridge pattern decouples an abstraction from its implementation so that the two can vary independently.”

Abstraction is a high-level interface that contains non-specific implementation of any control logic (or business logic).
The logic is separated from abstraction and it exists in a different object the “implementation object” which is responsible for the low-level work.

The abstraction contains a reference to the implementation object, therefore it can control its methods. Let’s dive into an example with the use of diagrams.

Step 2 —Diagrams
Design Bridge pattern by example

In this example, we have three animals that “move” in different ways:

Person that moves by walking. (We are all animals at the end of the day)
Fish that moves by swimming.
Bird that moves by flying.

Abstraction: It is only obvious that there is a pattern here. Three objects that move but in different ways. Why don’t we make an abstraction out of it?

As shown in the diagram, the class Animal is an abstraction (or interface) such that the three animals inherit from it. Each animal individually implements their own specific logic as to how they move(). Therefore, they declare their own move method.
However, we are still not quite there yet. Bridge pattern is NOT about a simple inheritance. The pattern’s intent is to separate the move()logic from the abstraction. In this example, the code within the Animal classes should only be about defining the animal object representations.

Implementation: Each move()method has a different logic (or control logic, or business logic). For example, a person walks by using his legs one at a time, a bird needs to flap its wings in a specific frequency and so on.

The diagram shows the full scale of the bridge pattern. The animals don’t implement their own move()methods but they have a MoveLogic object that they refer to. The move() implementation is decoupled from the Animal interface. The benefit is that the code in the Animal class is cleaner, easy to understand and smaller. Developers don’t need classes with thousand lines of code which is irrelevant to the object's definition. In addition, if in the future we would like to add a new class, for example, Reptilewe can use the existing Swim class instead of copy pasting the logic inside the Reptile class.

Step 3 — Code by example

I would suggest to copy the code class by class from my git repository “Andreas Poyias” or the snippets below (in the order provided) and paste it in any of the available online C++ editors like c++shell, jdoodle , onlineGDBand run it to observe the output. Then read the comments or description below. Take your time, reading it thoroughly (that means one minute, not less and not more).

Implementation:
First, we start with the implementation objects. We have the different types of movement likeWalk and Swim, inheriting fromMoveLogic. Each of those classes contains the logic required for the specificmove() function “hiding” the implementation from the Animals. This probably sounds familiar to another design pattern from a previous blog (the Facade pattern). The main difference between the two is the intent. One could easily say that the MoveLogic could as well be the Facade such that the Animal classes don’t contain and maintain the complexities of the move operation.

#include<iostream>
#include<string>
using namespace std;
 
class MoveLogic {
public:
    virtual void move() = 0;
};
 
class Walk : public MoveLogic {
public:
    void move() { cout << "Move alternating legs\n"; }
};
 
class Fly : public MoveLogic {
public:
    void move() { cout << "Flap wings\n"; }
};

Abstraction:
This is a simple inheritance from an interface. Each animal’s is constructor receives a MoveLogic object to be initialized. Then the animal can call the move() function where the move is going to perform the complicated logic that is required.

class Animal {
public:
    virtual void howDoIMove() = 0;
};
 
class Person : public Animal {
    MoveLogic* _myMoveLogic;
public:
    // Constructor receives the MoveLogic object to be initialized
    Person(MoveLogic *obj): _myMoveLogic(obj){}    void howDoIMove() {
        _myMoveLogic->move();
    }
};
 
class Bird : public Animal {
    MoveLogic* _myMoveLogic;
public:
    Bird(MoveLogic *obj) :_myMoveLogic(obj){}
    void howDoIMove() {
        _myMoveLogic->move();
    }
};

Main function
As always (in my examples) the main function operates as the client. The client’s job is simple. MoveLogic objects are created, then they are passed to the animals which use the decoupled move implementation.

int main() 
{
    MoveLogic* walk = new Walk();
    MoveLogic* fly  = new Fly();
 
    Animal* animalA = new Person(walk);
    Animal* animalB = new Bird(fly);
 
    animalA->howDoIMove();
    animalB->howDoIMove();
 
    return 1;
}// Output:
// Move alternating legs
// Flap wings

The next blog will be a quick guide to the Builder design pattern. It is a creational pattern which is a must have to your knowledge repository. Don’t forget to like/clap my blog-post and follow my account. This is to give me the satisfaction that I helped some fellow developers and push me to keep on writing. If there is a specific design pattern that you would like to learn about then let me know so I can provide it for you in the future.

Other quick-guides on design patterns:

This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

Design Patterns — A quick guide to Bridge pattern.

Written by Andreas Poyias