Bridge

Lets you split a large class or a set of closely related classes into two separate hierarchies—abstraction and implementation—which can be developed independently.

classDiagram
    class Abstraction {
        -Implementation implementation
        +operation()
    }
    class RefinedAbstraction {
        +operation()
    }
    class Implementation {
        <<interface>>
        +operationImplementation()
    }
    class ConcreteImplementationA {
        +operationImplementation()
    }
    class ConcreteImplementationB {
        +operationImplementation()
    }

    Abstraction o-- Implementation
    Abstraction <|-- RefinedAbstraction
    Implementation <|.. ConcreteImplementationA
    Implementation <|.. ConcreteImplementationB

When to use

Use the Bridge pattern when you want to divide and organize a monolithic class that has several variants of some functionality (for example, if the class can work with various database servers). Use when you need to extend a class in several orthogonal (independent) dimensions.

Explanation

Problem

Abstraction and Implementation? Suppose you have a geometric Shape class with a pair of subclasses: Circle and Square. You want to extend this class hierarchy to incorporate colors, so you plan to create Red and Blue shape subclasses. However, since you already have two subclasses, you’ll need to create four class combinations such as BlueCircle and RedSquare. Adding a new shape type or a new color requires growing the hierarchy exponentially.

Solution

The Bridge pattern solves this problem by switching from inheritance to object composition. What this means is that you extract one of the dimensions into a separate class hierarchy, so that the original classes will reference an object of the new hierarchy, instead of having all of its state and behaviors within one class.

Real world problem

Devices and Remotes: The Remote acts as the abstraction, and the Device (TV, Radio) interface acts as the implementation. You can develop remotes (Basic, Advanced) independently from devices (Sony, Samsung).
Cross-Platform Apps: A GUI framework (Abstraction) works with different OS APIs (Implementation: Linux, Windows, macOS).

Pros and Cons

Pros	Cons
- Platform-independent: You can create platform-independent classes and apps. - Client Code Agnostic: The client code works with high-level abstractions. It isn’t exposed to the platform details. - Open/Closed Principle: You can introduce new abstractions and implementations independently. - Single Responsibility Principle: You can focus on high-level logic in the abstraction and on platform details in the implementation.	- Complexity: You might make the code more complicated by applying the pattern to a highly cohesive class.

Pros

Cons

- Platform-independent: You can create platform-independent classes and apps.
- Client Code Agnostic: The client code works with high-level abstractions. It isn’t exposed to the platform details.
- Open/Closed Principle: You can introduce new abstractions and implementations independently.
- Single Responsibility Principle: You can focus on high-level logic in the abstraction and on platform details in the implementation.

- Complexity: You might make the code more complicated by applying the pattern to a highly cohesive class.

Comparison

Adapter: Bridge is usually designed up-front. Adapter is retrofitted.
State: Bridge, State, Strategy (and to some degree Adapter) have very similar structures (composition). Indeed, all of these patterns are based on composition, which is delegating work to other objects. However, they all solve different problems.