Bridge Design Pattern

Video Lecture

Section	Video Links
Bridge Pattern
Bridge Use Case

Overview

The Bridge pattern is similar to the Adapter except in the intent that you developed it.

The Bridge is an approach to refactor already existing code, whereas the Adapter creates an interface on top of existing code through existing available means without refactoring any existing code or interfaces.

The motivation for converting your code to the Bridge pattern is that it may be tightly coupled. There is logic and abstraction close together that is limiting your choices in how you can extend your solution in the way that you need.

E.g., you may have one Car class, that produces a very nice car.

const CAR = new Car()
> Car has wheels and engine and windows and everything else.

But you would like to delegate the engine dynamically from a separate set of classes or solutions.

const ENGINE = new EngineA()
const CAR = new Car(ENGINE)

The Bridge pattern is a process about separating abstraction and implementation, so this will allow you more ways of using your classes.

A Bridge didn't exist before, but since after the separation of interface and logic, each side can be extended independently of each other.

The Bridge pattern should use composition instead of inheritance. This means that you assign the relationship when the object is created at runtime rather than hard coded in the class definition.

I.e., CAR = new Car(EngineA) rather than class Car extends EngineA

A Bridge implementation will generally be cleaner than an Adapter solution that was bolted on. Since it involved refactoring existing code, rather than layering on top of legacy or third-party solutions that may not have been intended for your particular use case.

Terminology

• Abstraction Interface: An interface implemented by the refined abstraction describing the common methods to implement.
• Refined Abstraction: A refinement of an idea into another class or two. The classes should implement the Abstraction Interface and assign which concrete implementer.
• Implementer Interface: The implementer interface that concrete implementers implement.
• Concrete Implementer: The implementation logic that the refined abstraction will use.

Bridge UML Diagram

Source Code

In the concept demonstration code, imagine that the classes were tightly coupled. The concrete class would print out some text to the console.

After abstracting the class along a common ground, it is now more versatile. The implementation has been separated from the abstraction, and now it can print out the same text in two different ways.

The benefit now is that each refined abstraction and implementer can now be worked on independently without affecting the other implementations.

./src/bridge/bridge-concept.ts

// Bridge Pattern Use Case Sample Code

interface IAbstraction {
    method(value: string[]): void
}

class RefinedAbstractionA implements IAbstraction {
    #implementer: IImplementer

    constructor(implementer: IImplementer) {
        this.#implementer = implementer
    }

    method(value: string[]) {
        this.#implementer.method(value)
    }
}

class RefinedAbstractionB implements IAbstraction {
    #implementer: IImplementer

    constructor(implementer: IImplementer) {
        this.#implementer = implementer
    }

    method(value: string[]) {
        this.#implementer.method(value)
    }
}

interface IImplementer {
    method(value: string[]): void
}

class ConcreteImplementerA implements IImplementer {
    method(value: string[]) {
        console.log(value)
    }
}

class ConcreteImplementerB implements IImplementer {
    method(value: string[]) {
        value.forEach((v) => console.log(v))
    }
}

// The Client
const VALUES = ['a', 'b', 'c']

const REFINED_ABSTRACTION_A = new RefinedAbstractionA(
    new ConcreteImplementerA()
)
REFINED_ABSTRACTION_A.method(VALUES)

const REFINED_ABSTRACTION_B = new RefinedAbstractionB(
    new ConcreteImplementerB()
)
REFINED_ABSTRACTION_B.method(VALUES)

Output

node ./dist/bridge/bridge-concept.js
[ 'a', 'b', 'c' ]
a
b
c

SBCODE Editor

<>

Bridge Use Case

In this example, I draw a square and a circle. Both of these can be categorized as shapes.

The shape is set up as the abstraction interface. The refined abstractions, Square and Circle, implement the IShape interface.

When the Square and Circle objects are created, they are also assigned their appropriate implementers being SquareImplementer and CircleImplementer.

When each shape's draw method is called, the equivalent method within their implementer is called.

The Square and Circle are bridged and each implementer and abstraction can be worked on independently.

Example UML Diagram

Source Code

./src/bridge/client.ts

// Bridge Pattern Concept Sample Code

import CircleImplementer from './circle-implementer'
import SquareImplementer from './square-implementer'
import Circle from './circle'
import Square from './square'

const CIRCLE = new Circle(new CircleImplementer())
CIRCLE.draw()

const SQUARE = new Square(new SquareImplementer())
SQUARE.draw()

./src/bridge/circle-implementer.ts

import IShapeImplementor from './ishape-implementer'

export default class CircleImplementer implements IShapeImplementor {
    drawImplementation(): void {
        console.log('    ******')
        console.log('  **      **')
        console.log(' *          *')
        console.log('*            *')
        console.log('*            *')
        console.log(' *          *')
        console.log('  **      **')
        console.log('    ******')
    }
}

./src/bridge/square-implementer.ts

import IShapeImplementer from './ishape-implementer'

export default class SquareImplementer implements IShapeImplementer {
    drawImplementation(): void {
        console.log('**************')
        console.log('*            *')
        console.log('*            *')
        console.log('*            *')
        console.log('*            *')
        console.log('*            *')
        console.log('*            *')
        console.log('**************')
    }
}

./src/bridge/circle.ts

// A Circle Abstraction

import IShape from './ishape'
import IShapeImplementor from './ishape-implementer'

export default class Circle implements IShape {
    #implementer: IShapeImplementor

    constructor(implementer: IShapeImplementor) {
        this.#implementer = implementer
    }

    draw(): void {
        this.#implementer.drawImplementation()
    }
}

./src/bridge/square.ts

// A Square Abstraction

import IShape from './ishape'
import IShapeImplementor from './ishape-implementer'

export default class Square implements IShape {
    #implementer: IShapeImplementor

    constructor(implementer: IShapeImplementor) {
        this.#implementer = implementer
    }

    draw(): void {
        this.#implementer.drawImplementation()
    }
}

./src/bridge/ishape-implementer.ts

// The Shape Implementor Interface

export default interface IShapeImplementor {
    drawImplementation(): void
}

./src/bridge/ishape.ts

// The Shape Abstraction Interface

export default interface IShape {
    draw(): void
}

Output

node ./dist/bridge/client.js
    ******
  **      **
 *          *
*            *
*            *
 *          *
  **      **
    ******
**************
*            *
*            *
*            *
*            *
*            *
*            *
**************

SBCODE Editor

<>

Summary

• Use when you want to separate a solution where the abstraction and implementation may be tightly coupled, and you want to break it up into smaller conceptual parts.
• Once you have added the bridge abstraction, you should be able to extend each side of it separately without breaking the other.
• Also, once the bridge abstraction exists, you can more easily create extra concrete implementations for other similar products that may also happen to be split across similar conceptual lines.
• The Bridge pattern is similar to the adapter pattern except in the intent that you developed it. The bridge is an approach to refactor already existing code, whereas the adapter adapts to the existing code through its existing interfaces and methods without changing the internals.