The bridge pattern has the goal of decoupling an abstract concept from its concrete implementation so that the two can vary independently.
You could for example imagine having an abstraction of
Image that may be further refined into the abstract concept of
The idea of the bridge is that the abstract concept is composed of its concrete implementation and forward its method calls of to its concrete implementation.
In our example, we could for example imagine that
Image exposes the following methods (caution: the abstraction does not necessarily mean an abstract class):
Image.Draw() just calls
Image.DoubleSize() just calls
Image.Resize(factor) is an abstract method that shall be overridden by
The key intent is to let concrete implementations vary independently. For example:
BitmapImage.Resize(factor) would call
BitmapImage.ConcreteImage.Resize(factor) because how pixels are manipulated to compute the new pixels depend on the bitmap format and some policies defined for the bitmap.
VectorImage.Resize(factor) may just iterate through the shapes recorded in the picture, and for every shape change its properties based on some resizing transformation.
You could for example think of B&W, greyscale and RGB implementation of
BitmapImage. And likewise for
THe bridge is not the most used pattern and this example is pure fiction. But there's a real story behind on the NeXt platform. THe advantage is the extreme flexibility, since it allows two dimensions of variations. Often you end-up (as in my example) with family of implementations (here based on the color scheme).
If you finally have a great use-case for the bridge, the real problems start: how to create the objects without coupling the code to predefined implementation classes? Usually, the answer is to create a factory, e.g. create the right type of abstract
Image. However,it's also about the related implementations to be used. And maybe there are other forms of related objects such as filters or transformations. So you may need in the end to create families of related objects (e.g. abstractions and their related implementations). And this is exactly the intent of the abstract factory.
The GoF gives another interesting example (at least if you're in the framework business): they illustrate the bridge with different kind of windows (e.g. PopUp, Form, ...), each being associated with a GUI-specific concrete implementation (e.g. MS Windows pop-up and form, Presentation manager..., XWindows...). And they illustrate the abstract factory with concrete factories that are GUI specific (for creating windows implementations).
An abstract factory cand create and configure a particular brdige.