Bridge

Purpose

A Bridge expands on the service provided by inheritance, which lets multiple versions of an object be treated individually or similarly as needed. A Bridge adds an additional layer between the abstraction (superclass) and its implementation (subclasses).

Typically, if you change the superclass in an inheritance tree, all of the subclasses have to change as well. A Bridge lets these two change without that tight coupling, and lets it happen dynamically at runtime.

Design

The Bridge uses aggregation and inheritance to separate responsibilities into different sets of classes. Rather than everything inheriting from a single parent, the Bridge pattern breaks the problem into two inheritance trees.

This is useful when the tree wants to change in two dimensions at once. Alex at Mastering Software Development explains it with an example that finally made the pattern click for me: it turns this…

…into this:

This is done by moving the platform-specific Linux, Windows and Mac classes together on one side, separating them from the three types of scheduling which are common to all of those platforms.

Example

Autobot Robotics has several functions it requires its robotic arms to perform: using a drill to cut holes in a circuit board, placing a completed board into a box, and cleaning up the workspace when it gets too dirty. However, it wants the system to do all of this using three different robotic arm systems.

class client {
    public void start() {
        ArmApplications aa = new ArmApplications(new Arm601());
        aa.doActivity();
    }
}

class ArmApplications {
    protected ArmController localController;
    public ArmApplications(ArmController ac) { localController = ac; }
    public void doActivity();
}

class DrillHoles : ArmApplications {
    public void doActivity() {
        localController.moveArm();
    }
}

class PutInBox : ArmApplications { }   // same thing as DrillHoles
class Cleaner  : ArmApplications { }   // same thing as DrillHoles

class ArmController {
    public void moveArm();
}

class Arm601 : ArmController {
    public void moveArm() {
        // Do movement on specific arm type
    }
}

class Arm802  : ArmController { }   // same thing as Arm601
class Arm1210 : ArmController { }   // same thing as Arm601

Comparisons

• Adapter also stands between two sides, but it is applied after the fact to code you did not design. A Bridge is planned in advance. Same shape, opposite intent.
• Abstract Factory pairs naturally with a Bridge. It is a good way to decide which Implementor an Abstraction gets handed.
• Strategy looks nearly identical in UML. The difference is what varies: Strategy swaps an algorithm, Bridge swaps an entire platform or implementation, and Bridge expects both sides to keep growing.

Why It Exists

Criticisms

The Bridge solves a very specific type of problem. When it is needed, it is usually needed badly. However, it is an unusual pattern to actually need to implement, and reaching for it before the second axis of variation genuinely exists just buys you an extra layer of indirection for nothing.