Decouple an abstraction from its implementation so that the two can vary independently. (Gamma, 151)
A Bridge expands on the service provided by inheritance in OOP which allows multple versions of an object to be treated individually or similarly as needed. A Bridge adds an additional layer between the abstraction (superclass) and its implementation (subclasses). Typically, if you change the superclass in inheritance, all of the subclasses have to change as well. A bridge allows these two to change without such tight coupling and even do so dynamically.
The bridge uses aggregation and inheritance to seperate responsibilities into different sets of classes. Rather than everything inheriting from a single parent, the bridge pattern breaks the problem into two inheritance trees. This is useful if the tree seems to change in two dimensions. For example, this site explains how the bridge pattern turns this:
This is done by moving the platform specific linux,windows and mac classes together on one side to separate them from the three types of scheduling which are common to all of these platforms.
UML for a generic Bridge pattern (Gamma, 153)
Autobot Robotics has several functions that it requires its robotic arms to perform. Some examples of these include using a drill to cut holes in a circuit board, placing a completed circuit board into a box, and cleaning up the workspace when it gets too dirty. However, it wants the system to do this using three different robotic arm systems.
A bridge is similar to an adapter in that it stands between the adaptee and the target. It does this in such a way that a series of adapters can be selected to solve problems for either different targets or different adaptees.
The Bridge solves a very specific type of problem. When it is needed, it is usually needed badly. However, it is an unusual pattern to actually need to implement.