Editing Bridge pattern (section)

== Overview ==
The Bridge design pattern is one of the twenty-three well-known ''[[Design Patterns|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.{{r|GoFp151}}

What problems can the Bridge design pattern solve?<ref>{{cite web|title=The Bridge design pattern - Problem, Solution, and Applicability|url=http://w3sdesign.com/?gr=s02&ugr=proble|website=w3sDesign.com|access-date=2017-08-12}}</ref>
* 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 subclassing, 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.

What solution does the Bridge design pattern describe?
* Separate an abstraction (<code>Abstraction</code>) from its implementation (<code>Implementor</code>) by putting them in separate class hierarchies.
* Implement the <code>Abstraction</code> in terms of (by delegating to) an <code>Implementor</code> object.

This enables to configure an <code>Abstraction</code> with an <code>Implementor</code> object at run-time.
<br>
See also the [[Unified Modeling Language]] class and sequence diagram below.