Bridge Pattern: When Two Things Vary, Stop Multiplying Them

Someone once modelled shapes in a graphics engine the obvious way: a Shape base class, then Circle and Square under it. Then the product needed both vector output (for print) and raster output (for screen). So Circle sprouted VectorCircle and RasterCircle; Square sprouted VectorSquare and RasterSquare. Four classes.

Then a Triangle shipped — two more classes. Then the team added an SVG renderer for the web — and every existing shape needed an SvgCircle, SvgSquare, SvgTriangle. The grid is now 3 shapes × 3 renderers = nine classes, and the tenth renderer would demand three more. Every renderer knows how to draw every shape, and the drawing math for a circle is copy-pasted across VectorCircle, RasterCircle, and SvgCircle.

Nothing here is a single bad decision. The mistake is structural: shape and rendering are two things that vary independently, and a single inheritance tree can only branch on one of them at a time. Bolt the second dimension onto the same tree and you get its product, not its sum.

The intuition: a light switch and a wired thing

A wall switch does one job — flip a circuit between on and off. It does not know or care whether the wire behind it runs to a ceiling lamp, a fan, or a garage door. Swap the lamp for a fan and the switch is unchanged; add a dimmer switch and the lamp is unchanged.

The switch is the abstraction — the control surface, the “what you can ask for.” The wired device is the implementation — the “how it actually happens.” A single strand of copper joins them: the switch holds a reference to whatever is on the other end. That wire is the bridge. Neither side has to know the other’s catalogue, so each catalogue can grow on its own.

That has-a wire is the whole trick — and the members-only continuation makes it concrete: the two-hierarchy class diagram, the Java code where a single Device reference joins the axes, the Bridge-vs-Adapter-vs-Strategy distinction, the JDBC/SLF4J/driver examples, the M×N-vs-M+N tradeoffs, and an interview corner that refactors a notification class explosion.