When should you reach for Bridge over plain inheritance, Strategy, or Adapter — and when is it the wrong tool?

## The decision in one sentence Use **Bridge** when a concept varies along **two (or more) independent axes** that will both keep growing and you want to combine them freely — and you can see this coming when you design. ## Signals that Bridge fits - You can name **two orthogonal dimensions** (shape × renderer, notification type × delivery channel, document × export format). - **Both** dimensions are expected to **gain members** over time. - You're already feeling, or can foresee, the **M×N subclass explosion**. - You want to **choose the pairing at runtime** (e.g. pick the rendering backend by environment). ## Distinguishing it from the neighbours ### vs plain inheritance If only **one** dimension varies, just subclass. Inheritance is simpler and Bridge's indirection buys nothing. Bridge is specifically the answer when a *second* independent dimension shows up. ### vs Strategy **Strategy** plugs a single interchangeable **algorithm** behind one operation (e.g. a `Comparator` chooses how to sort). Structurally Strategy also holds a reference to an interface, so it resembles Bridge — but Strategy's intent is 'swap *one behavior*', and there's typically no parallel hierarchy of contexts that also grows. Bridge separates an **entire abstraction hierarchy** from an **entire implementation hierarchy**, with both sides open-ended. Rule of thumb: one algorithm slot → Strategy; two co-evolving hierarchies → Bridge. ### vs Adapter **Adapter** is a **retrofit**: you wrap an existing, often third-party, class to make its incompatible interface fit what you expect. It's reactive and joins interfaces that were designed apart. Bridge is **proactive**: you design two interfaces together, up front, to keep two dimensions independent. Same delegating skeleton, opposite intent and timing. ### vs Abstract Factory Abstract Factory is about **creating families** of related objects; it often *complements* Bridge by producing the right concrete implementor. They're not competitors — you can use a factory to choose which implementor a bridge gets. ## When Bridge is the WRONG tool - **Only one axis varies** → unnecessary indirection; subclass or a single interface. - **The second axis is fixed** and realistically won't grow → you've added two interfaces and a layer for nothing. - **Speculative generality / YAGNI**: you split into two hierarchies for variation that may never arrive, hurting readability now for a benefit that never lands. - **A simple retrofit is all you need** → that's Adapter, not Bridge. ## Costs to weigh - **Indirection**: every call hops abstraction → implementor, which can hurt readability and debuggability. - **Two interfaces to keep coherent**: the abstraction and implementor must evolve together; a poorly factored implementor interface (too high-level, or mirroring the abstraction) undermines the benefit. - **Discoverability**: newcomers must understand that behavior is split across two hierarchies. ## Terms defined - **Axis / dimension of variation**: an independent way a type can differ. - **Orthogonal**: independent — changing one axis doesn't constrain the other. - **Speculative generality / YAGNI ('You Aren't Gonna Need It')**: adding flexibility for needs that haven't materialized; a recognized smell. - **Strategy / Adapter / Abstract Factory**: neighbouring patterns contrasted above. ## Bottom line Bridge earns its keep exactly when **two real, growing, independent dimensions** meet and you want their combinations cheap. Outside that, prefer the simpler tool (inheritance, Strategy, or Adapter) — applying Bridge to a single axis is over-engineering.