Bridge Pattern Is Just Good Factoring

I used to think I was pretty smart, but I'm just not getting this. I'm starting to think the BridgePattern isn't anything, not even a pattern, and the same for ShieldPattern. Let me just blurt my thoughts out directly: I don't mean the following to sound didactic or rude.

Any class can implement any protocol. Duh. Therefore if (to take the GoF example for Bridge) I implement multiple classes all to use the same protocol, that's polymorphism, no more, no less.

I devise an Interface to a Window. I write it on a card, or type it into Java. Then I implement a class implementing the interface, e.g. ApplicationWindow. Then I implement another, IconWindow.

These two classes have code in common. I factor out an object (Window) that contains the common elements, and leave just the "primitives" in ApplicationWindow and IconWindow. The Window class can have an ApplicationWindow or an IconWindow instance to support the actual drawing.

Repeated application of refactoring rules (removing duplicate code, mostly) will convert two classes, e.g. ApplicationWindow and IconWindow, with the same starting protocol, into Window, ApplicationWindow, and IconWindow.

Bridge seems to me to be JustGoodFactoring.

Please ... enlighten me. -- RonJeffries

Ron, you are right, Bridge is just good factoring. But don't assume that the obvious (things that generate the Duh reactions) isn't worth documenting as patterns.

One of the goal of the software patterns movement (in my opinion) is to capture the obvious in pattern form.

When I run into a good pattern that I just don't get, I (may) go through the following stages:

  1. I look at it suspiciously...
  2. I get confused...
  3. I start questioning the way I do things...
  4. I am hit by the AhHa experience...
  5. I eventually implement the pattern or figure out that I already have implemented the pattern..
  6. I go Duh (this pattern is pretty obvious) and move on.

Some patterns never make it pass stage 2 for me. When I am open minded, they can reach stage 3 before I chuck them. (Often, I come back to it months later and I slip into stage 4). Unfortunately, for me, sometimes it takes months to get to stage 6. Patterns often remind me of how little I actually understand...

But, when I encounter a pattern that seems pretty obvious (e.g. Bridge), I usually jump to stage 5 or 6. Now, guess what, I have made that pattern part of my lexicon. I can shout: 'Bridge, bridge, bridge... don't forget to build a bridge' and everyone knows what I mean.

I have worked with really smart developers who shun patterns, yet there are patterns strewn throughout their work.

-- ToddCoram

The point is not so much that it's obvious, but that it's subsumed by another pattern. If we know the larger pattern - if we know how to factor well - do we gain anything by having Bridge?

Probably yes. I suspect Bridge is easier to teach than GoodFactoring?, and easier to apply. It's more specific.

-- DaveHarris

I put my comments in HowDoAntsWalkInaStraightLine. I can't get out of the ant business, but I guess I want to do something about it. -- AlistairCockburn
Bridge is not just good factoring. I was going to say it was, but then I read it again.

For example, let's say you want to have a Collection class whose implementation varies based on how many elements it contains. You would split the class into two parts, one of which provided identity and the usual collection protocol to the outside world, and a second which is a family of implementations, Empty, SingleElement?, Linear, and Hashed, for example. The Collection object is a Bridge to the implementations.

Why isn't this just Strategy or State? JohnVlissides says, "After a while, everything looks like a Strategy." (See StrategyPattern and StatePattern.)

So, it's more than just factoring, but I don't think it's any more than is contained in the other DesignPatterns.

--KentBeck

Note that JustIsaDangerousWord. --ChristofferHammarstrom.

It could be that we should always DesignAndDevelopWithFactoringInMind?. When you do that, you end up using all these patterns without even realizing, and “After a while, everything looks like a Strategy”. – GastónNusimovich

EditText of this page (last edited May 17, 2004)
FindPage by browsing or searching

This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004