Structural Design Pattern: Bridge Design Pattern

Define Bridge Design Pattern

The bridge design is used to separate concepts and implementation so that they can be adjusted independently. This pattern includes an interface that serves as a bridge between the abstraction and implementer classes, as well as making the implementer's functionality independent of the abstraction.

Bridge Design pattern with UML diagram

The classes, interfaces, & objects in the above UML class diagram are listed as follows:

• Abstraction: This is an abstract class with members that define an abstract business item and its capabilities. It references a Bridge-type object. It can also serve as a foundational class for other abstractions.
• Redefined Abstraction: This class is derived from the Abstraction class. It extends the interface defined by the Abstraction class.
• Bridge: This interface serves as a link between the abstraction and implementer classes, allowing the implementer class's functionality to be independent of the abstraction class.
• ImplementationA and ImplementationB: These classes implement the Bridge interface and give implementation details for the corresponding Abstraction class.

When to use a Bridge Design pattern?

• The bridge design pattern is useful for independently modifying abstractions and implementations.
• Changes in the implementation of an abstraction should not affect clients.
• The Bridge pattern is used when a new version of a software or system is released while the older version of the software continues to run for its existing clients. There is no need to alter the client code; nevertheless, the client must pick which version to use.

Advantages of the Bridge Design Pattern:

• Decoupling: It separates an abstraction from its implementation, allowing it to change independently.
• Single Responsibility concept: It advances the idea by separating an abstraction from its application.
• Flexibility: Increases framework and implementation flexibility.
• Extensibility: Abstractions and implementations can be extended separately.
• Prevents Cartelization: Prevents Cartelization prevents the 'cartesian product' complexity explosion. For example, if you have N abstractions and M implementations, you do not require N*M classes.