Design Patterns Explained
  • Getting Started
  • SOLID Principles
    • Single Responsibility Principle
    • Open / Closed Principle
    • Liskov Substitution Principle
    • Interface Segregation Principle
    • Dependency Inversion Principle
  • Design Patterns
    • Creational Patterns
      • Abstract Factory Pattern
      • Builder Pattern
      • Factory Pattern
      • Prototype Pattern
      • Singleton Pattern
    • Behavioral Patterns
      • Chain Of Responsibility Pattern
      • Command Pattern
      • Interpreter Pattern
      • Iterator Pattern
      • Mediator Pattern
        • Example 1
      • Memento Pattern
      • Observer Pattern
      • State Pattern
      • Strategy Pattern
        • Example 1
      • Template Method Pattern
      • Visitor Pattern
    • Structural Patterns
      • Adapter Pattern
      • Bridge Pattern
      • Composite Pattern
      • Decorator Pattern
      • Facade Pattern
      • Flyweight Pattern
      • Proxy Pattern
  • Roadmap
Powered by GitBook
On this page
  • When to use
  • Structure
  • Note
  • Examples

Was this helpful?

  1. Design Patterns
  2. Structural Patterns

Bridge Pattern

PreviousAdapter PatternNextComposite Pattern

Last updated 4 years ago

Was this helpful?

Decouples an abstraction from its implementation so that the two can vary independently.

When to use

  1. You want to decouple a huge monolithic class that's responsible for many things.

  2. You want to avoid permenent binding between an abstraction and its implementation, especially when the implementation can be switched at run-time.

  3. You want to avoid making many subclasses for each implementation if the abstraction is the same but has more than a valid implementation.

Structure

  • Abstraction: defines the abstraction's interface, and maintains a reference to an object of type Implementor.

  • RefinedAbstraction: optional either extends the features of the abstraction, or makes a variant of the Abstraction.

  • Implementor: defines the interface for implementation classes, usually the Implementor provides only primitive (low-level) operations, and then the Abstraction do a higher-level operation based on there primitives.

  • ConcreteImplementor: implements the Implementor interface and defines its concrete implementation.

Note

  • Be careful as the more cohesive the class is, the harder it becomes to implement the bridge pattern and may introduce more complexity.

  • The pattern is a great example for Single Responsibility Principle, as it decouples the different functionalities to its own interfaces and implementations.

  • The pattern is also a great example for Dependency Inversion Principle, as after decoupling the different functionalities, the class will depend on an abstraction of the Implementor instead of the concrete implementations, also Dependency Injection will be used when explicitly defining the dependency of the Implementor in the constructor (or any other way of Dependency Injection).

Examples

Source Code

UML

// TODO

You can find the tests .

here
Example 1