The Bridge pattern is a kind of super Strategy pattern, that is, it is a way of encapsulating alternate versions of a whole range of methods rather than encapsulating alternate versions of just one method.
The problem is that you may have a set of methods that you contemplate implementing in two or more completely different ways. You don't want to have to mess up the rest of your code with the details of the different implementations.
The solution is to write a base class Interface that includes more or less empty implementations of the methods you need, and then to derive off Implementation child classes that provide concrete implementations of these methods. In the rest of the program, you program towards the somewhat abstract interface of the Interface object without worrying about the details of the Implementation children.
The UML diagram (Figure 5.8) is very similar to that for the Strategy pattern.
Learning about the Bridge pattern was crucial for the development of the Pop Framework code. The author had initially targeted the code throughout for Windows graphics calls. But then the time came to try and support OpenGL graphics. How to port to OpenGL graphics without losing all the work done implementing for Windows graphics and without, God forbid, developing two alternate versions of the same program. The solution was to abstract out an interface of all the graphics calls needed for Windows graphics or OpenGL graphics and to form a cGraphics class with prototypes for all these methods. Derived from this class are the cGraphicsMFC class and the cGraphicsOpenGL class. The CPopView window object owns a cGraphics *_pgraphics member which can in fact be dynamically changed between being cGraphicsMFC or cGraphicsOpenGL. For each 'behave' graphics call inside CPopView the code is now passed to a virtual _pgraphics->behavealgorithm call. Depending on the type of _pgraphics, the behavealgorithm call is then dynamically shunted to the Windows graphics or to the OpenGL graphics code.
Now that we have this instance of the Bridge pattern in place, a further port to DirectX graphics should be non-problematic (emphasis on should because one never knows with software engineering projects)!