The Bridge design pattern solves problems like:
How can an abstraction and its implementation vary independently?
How can an implementation be selected and exchanged at run-time?
See Applicability section for all problems Bridge can solve. See Solution section for how Bridge solves the problems.

• The standard way is to implement an abstraction by inheritance, i.e., different (sub)classes (Implementor1,…) implement the abstraction (interface) in different ways.
• This commits (binds) the implementation to an abstraction at compile-time and makes it impossible to change the implementation at run-time.
  "Inheritance binds an implementation to the abstraction permanently, which makes it difficult to modify, extend, and reuse abstractions and implementations independently. [GoF, p151]
• That's the kind of approach to avoid if we want that an implementation can be selected and exchanged at run-time instead of committing to an implementation at compile-time.
• For example, a reusable application that supports different hardware environments.
  To make an application portable across different hardware environments, it should be possible to select the proper hardware-specific implementation at run-time.