Bridge Pattern

Intent: The BridgePattern decouples an abstraction from its implementation so that the two can vary independently. This is unlike the intent of the AdapterPattern, which exists only to adapt the interface of one class to another.

One could say that both the AdapterPattern and the BridgePattern are specializations of JimCoplien's EnvelopeLetter (or HandleBody) idiom.

On the other hand, some people think that BridgePatternIsJustGoodFactoring. Or that it is an example of the ShieldPattern.

The BridgePattern is commonly known as "Driver". E.g. Printer driver, graphics driver, sound driver, etc.

Actually, I think that a "driver" is an example of the BridgePattern.

Device drivers? Aaaaaah (OverUsedOopExamples) -top

See also: AdapterPattern, DesignPatterns

Adapter is used to adapt two different classes to operate in a unified way. The adapter is the solution for classes that do similar jobs but don't have a unified interface. Adapter provides the uniform interface and can be implemented using either multiple inheritance or delegation through embedding a member of the adaptee. The major difference between adapter and bridge is when they are used. Adapter is used when two incompatible interfaces have to be unified together, ie., adapter is a result of existing incompatibilities. But bridge is something we use when we actually need to separate interface from implementation. Varying types of implementation is one reason. -- Praveen

My understanding of a bridge is this:

You're writing some code to do something. But, say half the code is dependent on what particular computer or platform you're working on, and half the code is independent of those details.

So, you "bridge" it. Whenever the code does something system dependent, you call the other side of the bridge. It does the system dependent stuff. And then it gets back, you trust that it did what it was supposed to do. So, you separate the abstract operations from the system-dependent operations, and you have a bridge between them.

Now, how does this differ from an adaptor?

Totally different. An adaptor is just something for working one interface to fit another interface. The two interfaces "mean" the same thing, (or roughly the same thing,) they just do it in a different shape. So you put an adaptor between them.

If you had a stereo system, and some head phones, and the stereo output the sound by a different interface than the head phones, that's an adaptor but not a bridge.

A bridge is by design. An adaptor is not. An adaptor is a patch. A bridge is put in place on purpose.

There's nobody on Earth who says, "Ahh,.... Yes, I am the brilliant person who bridged the listening device and the recording playback device." There's no such person. It doesn't make sense to say that it's a bridge.

And the adaptor is a thing that sits between the two interfaces. In a bridge, there isn't a thing that sits between two interfaces. The interfaces connect directly in a Bridge. It's a tight coupling. No adaptors sitting between the two halves.

And a bridge exists for a specific purpose. It exists to isolate system-dependent stuff. There are many interfaces between things, for many purposes.

If you're writing a video game, and you have specific classes for specific execution environments, then that's a bridge. But if you are isolating something else, say message handlers, and part of a ComponentBus architecture, then that's not a bridge any more. The reason a ComponentBus is not a bridge is that the purpose isn't to isolate system-dependent stuff. Sure, it may look like a bridge. There are two elements communicating by an interface, right? But it's not a bridge.

We have the word "Bridge" to say something specific. We mean to say, "This is a situation where the programmer thought it would be best to isolate the handling of the system-dependent stuff from the handling of the system-independent stuff."

The BridgePattern is very useful when you would otherwise have to deal with a CartesianProduct of implementations. If half the code is OS-dependent and half the code is CPU-dependent, then you have (#OSes)*(#CPUs) implementations to write. If you use a bridge, you have (#OSes)+(#CPUs) to write. (If you can use a bridge in this particular situation.)

DoubleDispatchExample provides possible implementations (OO and non-OO) using printer brand versus shapes.