Bridge pattern

The bridge pattern is a design pattern used in software engineering that is meant to "decouple an abstraction from its implementation so that the two can vary independently", introduced by the Gang of Four. The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes.

When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class and what it does vary often. The class itself can be thought of as the abstraction and what the class can do as the implementation. The bridge pattern can also be thought of as two layers of abstraction.

When there is only one fixed implementation, this pattern is known as the pointer-to-implementation idiom (or PIMPL idiom) in C++ contexts; the "pointer" here refers to an opaque pointer. Other names are "handle classes" and "compiler firewall idiom"; in Qt and KDE, they are known as the "d-pointer" and "Cheshire Cat" sometimes.

The bridge pattern is often confused with the adapter pattern, and is often implemented using the object adapter pattern.

Variant: The implementation can be decoupled even more by deferring the presence of the implementation to the point where the abstraction is utilized.

Overview

The Bridge design pattern is one of the twenty-three well-known GoF design patterns that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.

The bridge pattern solves these problems:

• An abstraction and its implementation should be defined and extended independently from each other.
• A compile-time binding between an abstraction and its implementation should be avoided so that an implementation can be selected at run-time.

When using inheritance, different subclasses implement an abstract class in different ways. But an implementation is bound to the abstraction at compile-time and cannot be changed at run-time.

The Bridge design pattern describes the following solutions:

• Separate an abstraction (Abstraction) from its implementation (Implementor) by putting them in separate class hierarchies.
• Implement the Abstraction in terms of (by delegating to) an Implementor object.

This enables to configure an Abstraction with an Implementor object at run-time.
See also the Unified Modeling Language class and sequence diagram below.

PIMPL idiom

Traditionally, the PIMPL idiom was used in C++ to decouple the class's API from its implementation, as well as guarantee ABI stability. It guarantees ABI stability by hiding the data behind a fixed-size pointer (an opaque pointer), allowing for changes to be made to a class's implementation without breaking binary compatibility. Additionally, private data can be completely made absent from client-facing code, providing stronger encapsulation.

The PIMPL idiom traditionally increases compilation speed by limiting cascading recompilations when a private member changes; additionally, with header files, dependencies can be prevented from leaking into clients via separate compilation; this also allows consumers only to compile large dependencies once (in the implementation file), rather than multiple times per inclusion. However, since C++20, modules achieve the same compilation speed improvements of the PIMPL idiom as a module is compiled only once, unlike a header.

However, using the PIMPL idiom has a small indirection cost, as each data access must go through a pointer dereference, and the objects reside on the heap.

Structure

UML class and sequence diagram

A sample UML class and sequence diagram for the Bridge design pattern.

In the above Unified Modeling Language class diagram, an abstraction (Abstraction) is not implemented as usual in a single inheritance hierarchy. Instead, there is one hierarchy for an abstraction (Abstraction) and a separate hierarchy for its implementation (Implementor), which makes the two independent from each other. The Abstraction interface (operation()) is implemented in terms of (by delegating to) the Implementor interface (imp.operationImp()).
The UML sequence diagram shows the run-time interactions: The Abstraction1 object delegates implementation to the Implementor1 object (by calling operationImp() on Implementor1), which performs the operation and returns to Abstraction1.

Class diagram

Abstraction (abstract class)

defines the abstract interface

maintains the Implementor reference.

RefinedAbstraction (normal class)

extends the interface defined by Abstraction

Implementor (interface)

defines the interface for implementation classes

ConcreteImplementor (normal class)

implements the Implementor interface

Bridge in LePUS3 (legend)

Example

C#

Bridge pattern compose objects in tree structure. It decouples abstraction from implementation. Here abstraction represents the client from which the objects will be called. An example implemented in C# is given below

namespace Wikipedia.Examples;

using System;

// Helps in providing truly decoupled architecture
interface IBridge
{
    void Function1();
    void Function2();
}

class Bridge1 : IBridge
{
    public void Function1()
    {
        Console.WriteLine("Bridge1.Function1");
    }

    public void Function2()
    {
        Console.WriteLine("Bridge1.Function2");
    }
}

class Bridge2 : IBridge
{
    public void Function1()
    {
        Console.WriteLine("Bridge2.Function1");
    }

    public void Function2()
    {
        Console.WriteLine("Bridge2.Function2");
    }
}

interface IAbstractBridge
{
    void CallMethod1();
    void CallMethod2();
}

class AbstractBridge : IAbstractBridge
{
    public IBridge bridge;

    public AbstractBridge(IBridge bridge)
    {
        this.bridge = bridge;
    }

    public void CallMethod1()
    {
        this.bridge.Function1();
    }

    public void CallMethod2()
    {
        this.bridge.Function2();
    }
}

The Bridge classes are the Implementation that uses the same interface-oriented architecture to create objects. On the other hand, the abstraction takes an instance of the implementation class and runs its method. Thus, they are completely decoupled from one another.

Crystal

abstract class DrawingApi
  abstract def draw_circle(x : Float64, y : Float64, radius : Float64)
end

class DrawingApiA < DrawingApi
  def draw_circle(x : Float, y : Float, radius : Float)
    "ApiA.circle at #{x}:#{y} - radius: #{radius}"
  end
end

class DrawingApiB < DrawingApi
  def draw_circle(x : Float64, y : Float64, radius : Float64)
    "ApiB.circle at #{x}:#{y} - radius: #{radius}"
  end
end

abstract class Shape
  protected getter drawing_api : DrawingApi

  def initialize(@drawing_api)
  end

  abstract def draw
  abstract def resize_by_percentage(percent : Float64)
end

class CircleShape < Shape
  getter x : Float64
  getter y : Float64
  getter radius : Float64

  def initialize(@x, @y, @radius, drawing_api : DrawingApi)
    super(drawing_api)
  end

  def draw
    @drawing_api.draw_circle(@x, @y, @radius)
  end

  def resize_by_percentage(percent : Float64)
    @radius *= (1 + percent/100)
  end
end

class BridgePattern
  def self.test
    shapes = [] of Shape
    shapes << CircleShape.new(1.0, 2.0, 3.0, DrawingApiA.new)
    shapes << CircleShape.new(5.0, 7.0, 11.0, DrawingApiB.new)

    shapes.each do |shape|
      shape.resize_by_percentage(2.5)
      puts shape.draw
    end
  end
end

BridgePattern.test

Output

ApiA.circle at 1.0:2.0 - radius: 3.075
ApiB.circle at 5.0:7.0 - radius: 11.275

C++

Bridge pattern

import std;

using std::string;
using std::vector;

class DrawingApi {
public:
    virtual ~DrawingApi() = default;
    virtual string drawCircle(float x, float y, float radius) const = 0;
};

class DrawingApiA: public DrawingApi {
public:
    [[nodiscard]]
    string drawCircle(float x, float y, float radius) const override {
        return std::format("ApiA.circle at {}:{} - radius: {}", x, y, radius); 
    }
};

class DrawingApiB: public DrawingApi {
public:
    [[nodiscard]]
    string drawCircle(float x, float y, float radius) const override {
        return std::format("ApiB.circle at {}:{} - radius: {}", x, y, radius);
    }
};

class Shape {
protected:
    const DrawingApi& drawingApi;
public:
    Shape(const DrawingApi& api):
        drawingApi{api} {}

    virtual ~Shape() = default;

    virtual string draw() const = 0;
    virtual float resizeByPercentage(const float percent) noexcept = 0;
};

class CircleShape: public Shape {
private:
    float x;
    float y;
    float radius;
public:    
    CircleShape(const DrawingApi& api, float x, float y, float radius): 
        Shape(api), x{x}, y{y}, radius{radius} {}

    [[nodiscard]]
    string draw() const override {
        return drawingApi.drawCircle(x, y, radius);
    }

    [[nodiscard]]
    float resizeByPercentage(float percent) noexcept override {
        return radius *= (1.0f + percent / 100.0f);
    }
};

int main(int argc, char* argv[]) {
    const DrawingApiA api1;
    const DrawingApiB api2;
    vector<CircleShape> shapes { 
        CircleShape(api1, 1.0f, 2.0f, 3.0f), 
        CircleShape(api2, 5.0f, 7.0f, 11.0f),
    }; 

    for (CircleShape& shape: shapes) {
        shape.resizeByPercentage(2.5);
        std::println("{}", shape.draw());
    }

    return 0;
}

Output:

ApiA.circle at 1.000000:2.000000 - radius: 3.075000
ApiB.circle at 5.000000:7.000000 - radius: 11.275000

PIMPL idiom

This example demonstrates the PIMPL idiom, with an internal Widget::Impl class held by a std::unique_ptr. Even using modules, the class declaration and implementation remain in separate files (the "module interface unit" and the "module implementation unit").

The module interface unit, Foo.cppm:

export module wikipedia.examples.Foo;

import std;

using std::string;
using std::unique_ptr;

namespace wikipedia::examples {

export class Foo {
private:
    struct Impl;
    unique_ptr<Impl> impl;
public:
    explicit Foo(string name);
    ~Foo() = default;

    Foo(Foo&& other) noexcept = default;
    Foo& operator=(Foo&& other) noexcept = default;

    Foo(const Foo&) = delete;
    Foo& operator=(const Foo&) = delete;

    void doSomething();
};

}

The module interface unit, Foo.cpp:

module wikipedia.examples.Foo;

using std::string;
using std::vector;

namespace wikipedia::examples {

struct Foo::Impl {
    string name;
    vector<int> internalCache;

    void internalLogic() {
        std::println("Processing {} cache...", name);
    }
};

Foo::Foo(string name):
    impl{std::make_unique<Impl>(Impl {.name = std::move(name)})} {}

void Foo::doSomething() {
    std::println("Action on {} internally...", impl->name);
    impl->internalLogic();
}

}

Java

The following Java program defines a bank account that separates the account operations from the logging of these operations.

package org.wikipedia.examples;

// Logger has two implementations: info and warning
@FunctionalInterface
interface Logger {
    void log(String message);
    
    static Logger info() {
        return message -> System.out.printf("info: %s%n", message);
    }
    static Logger warning() {
        return message -> System.out.printf("warning: %s%n", message);
    }
}

abstract class AbstractAccount {
    private Logger logger = Logger.info();
    
    public void setLogger(Logger logger) {
        this.logger = logger;
    }
    
    // the logging part is delegated to the Logger implementation
    protected void operate(String message, boolean result) {
        logger.log(String.format("%s result %s", message, result));
    }
}

class SimpleAccount extends AbstractAccount {
    private int balance;
    
    public SimpleAccount(int balance) {
        this.balance = balance;
    }
    
    public boolean isBalanceLow() {
        return balance < 50;
    }
    
    public void withdraw(int amount) {
        boolean shouldPerform = balance >= amount;
        if (shouldPerform) {
            balance -= amount;
        }
        operate(String.format("withdraw %s", amount, shouldPerform));
    }
}

public class BridgeDemo {
    public static void main(String[] args) {
        SimpleAccount account = new SimpleAccount(100);
        account.withdraw(75);
        
        if (account.isBalanceLow()) {
            // you can also change the Logger implementation at runtime
            account.setLogger(Logger.warning());
        }
        
        account.withdraw(10);
        account.withdraw(100);
    }
}

It will output:

info: withdraw 75 result true
warning: withdraw 10 result true
warning: withdraw 100 result false

PHP

interface DrawingApi
{
    function drawCircle($x, $y, $radius);
}

class DrawingApiA implements DrawingApi
{
    public function drawCircle($x, $y, $radius)
    {
        echo "ApiA.circle at $x:$y radius $radius.\n";
    }
}

class DrawingApiB implements DrawingApi
{
    public function drawCircle($x, $y, $radius)
    {
        echo "ApiB.circle at $x:$y radius $radius.\n";
    }
}

abstract class Shape
{
    protected $drawingApi;

    public abstract function draw();
    public abstract function resizeByPercentage($percent);

    protected function __construct(DrawingApi $drawingApi)
    {
        $this->drawingApi = $drawingApi;
    }
}

class CircleShape extends Shape
{
    private $x;
    private $y;
    private $radius;

    public function __construct($x, $y, $radius, DrawingApi $drawingApi)
    {
        parent::__construct($drawingApi);
        $this->x = $x;
        $this->y = $y;
        $this->radius = $radius;
    }

    public function draw()
    {
        $this->drawingApi->drawCircle($this->x, $this->y, $this->radius);
    }

    public function resizeByPercentage($percent)
    {
        $this->radius *= $percent;
    }
}

class Tester
{
    public static function main()
    {
        $shapes = array(
            new CircleShape(1, 3, 7,  new DrawingApiA()),
            new CircleShape(5, 7, 11, new DrawingApiB()),
        );

        foreach ($shapes as $shape) {
            $shape->resizeByPercentage(2.5);
            $shape->draw();
        }
    }
}

Tester::main();

Output:

ApiA.circle at 1:3 radius 17.5
ApiB.circle at 5:7 radius 27.5

Scala

trait DrawingApi {
  def drawCircle(x: Double, y: Double, radius: Double)
}

class DrawingApiA extends DrawingApi {
  def drawCircle(x: Double, y: Double, radius: Double) = println(s"Api A $x $y $radius")
}

class DrawingApiB extends DrawingApi {
  def drawCircle(x: Double, y: Double, radius: Double) = println(s"Api B $x $y $radius")
}

abstract class Shape(drawingApi: DrawingApi) {
  def draw()
  def resizePercentage(percent: Double)
}

class CircleShape(x: Double, y: Double, var radius: Double, drawingApi: DrawingApi)
    extends Shape(drawingApi: DrawingApi) {

  def draw() = drawingApi.drawCircle(x, y, radius)

  def resizePercentage(percent: Double) { radius *= percent }
}

object BridgePattern {
  def main(args: Array[String]) {
    Seq (
	new CircleShape(1, 3, 5, new DrawingApiA),
	new CircleShape(4, 5, 6, new DrawingApiB)
    ) foreach { x =>
        x.resizePercentage(3)
        x.draw()			
      }	
  }
}

Python

from abc import ABCMeta, abstractmethod
from typing import NoReturn

class DrawingApi:
    __metaclass__ = ABCMeta

    @abstractmethod
    def draw_circle(self, x: float, y: float, radius: float) -> NoReturn:
        raise NotImplementedError("Not implemented yet!")

class DrawingApiA(DrawingApi):
    def draw_circle(self, x: float, y: float, radius: float) -> str:
        return f"Api1.circle at {x}:{y} - radius: {radius}"

class DrawingApiB(DrawingApi):
    def draw_circle(self, x: float, y: float, radius: float) -> str:
        return f"Api2.circle at {x}:{y} - radius: {radius}"

class DrawingApiC(DrawingApi):
    def draw_circle(self, x: float, y: float, radius: float) -> str:
        return f"Api3.circle at {x}:{y} - radius: {radius}"

class Shape:
    __metaclass__ = ABCMeta

    drawing_api: DrawingApi = None
    def __init__(self, drawing_api: DrawingApi) -> None:
        self.drawing_api = drawing_api

    @abstractmethod
    def draw(self) -> NoReturn:
        raise NotImplementedError("Not implemented yet!")

    @abstractmethod
    def resize_by_percentage(self, percent: float) -> NoReturn:
        raise NotImplementedError("Not implemented yet!")

class CircleShape(Shape):
    def __init__(self, x: float, y: float, radius: float, drawing_api: DrawingApi):
        self.x = x
        self.y = y
        self.radius = radius
        super(CircleShape, self).__init__(drawing_api)


    def draw(self) -> str:
        return self.drawing_api.draw_circle(self.x, self.y, self.radius)

    def resize_by_percentage(self, percent: float) -> None:
        self.radius *= 1 + percent / 100


class BridgePattern:
    @staticmethod
    def test() -> None:
        shapes: list[CircleShape] = [
            CircleShape(1.0, 2.0, 3.0, DrawingApiA()),
            CircleShape(5.0, 7.0, 11.0, DrawingApiB()),
            CircleShape(5.0, 4.0, 12.0, DrawingApiC()),
        ]

        for shape in shapes:
            shape.resize_by_percentage(2.5)
            print(shape.draw())

if __name__ == "__main__":
    BridgePattern.test()

See also

• Adapter pattern
• Strategy pattern
• Template method pattern

External links

• Bridge in UML and in LePUS3 (a formal modelling language)
• C# Design Patterns: The Bridge Pattern From: James W. Cooper (2003). C# Design Patterns: A Tutorial. Addison-Wesley. ISBN 0-201-84453-2.