Bridge Pattern Is Just Good Factoring

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 WriteItOnaCard, or type it into Java. Then I implement a class implementing the interface; for example, 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 any two classes, like ApplicationWindow and IconWindow, with the same starting protocol, into Window, ApplicationWindow, and IconWindow.

Bridge seems to me to be JustGoodFactoring.

Please ... enlighten me. -- RonJeffries

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.

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

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

-- DaveHarris

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

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

        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.

        1. Unaware of a disability (, lack in skill, whatever)
        2. One becomes aware of the lack in skill (i.e. seeing others 'do patterns' or 'driving a car')
        3. One is aware of the skill just learned
        4. A skill becomes part of ones being (i.e flying a plane ;-)! )

Enter: OffTopic :p

This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006