Bridge and Strategy both have an object delegating to an injected interface. What actually distinguishes them?
answer
- One algorithm vs whole platform
- Strategy: behavioural; Bridge: structural
- Bridge needs a second hierarchy (M×N)
- Per-call swap vs lifetime pairing
- Strategy fills a policy hole; Bridge supplies the only mechanism
basics
~20 sStrategy swaps one interchangeable algorithm for a single operation and is often changed per call. Bridge splits an entire abstraction from an entire implementation platform, usually fixed for the object's life, to stop a two-dimensional class explosion.
solid answer
~60 sMechanically they are near-identical — an object holds an interface reference and delegates — so distinguish them by scope, granularity and intent. **Strategy is behavioural**: the injected object is *one algorithm* for *one decision* (which sorting order, which pricing rule, which retry policy). The host class is otherwise complete without it; the strategy is a policy hole. It is typically swappable per call or per request, and there is often no second hierarchy on the host side. **Bridge is structural**: the injected object is a whole *implementation platform* exposing several primitives, and the host is one member of a *parallel hierarchy* that exists precisely because two axes vary. The pairing is normally decided at construction and stable for the object's lifetime. Practical tells: does the injected interface have one method that answers one question (Strategy), or several primitives the host composes (Bridge)? Is there a matching hierarchy on the other side that would otherwise explode combinatorially (Bridge)? Would you swap it mid-flight per input (Strategy)? Also relevant: intent drives naming for readers and maintainers, and a design can legitimately be described as both.
go deeper
Say Strategy swaps one algorithm; Bridge separates a whole abstraction from a whole implementation to avoid a class explosion. One example of each.
Add the observable tells: single-method interface vs several primitives, presence of a second hierarchy, per-call swap vs lifetime pairing.
Argue from intent and evolution — what motivates each (removing conditionals vs preventing M×N and enabling independent deployment), and note nesting and honestly ambiguous cases.
Focus on the consequences of the label: interface stability and versioning policy, who may extend which side, and whether the seam is a released contract or an internal policy hole.
## Why the confusion is legitimate GoF classifies Bridge as **structural** (how objects are composed into larger structures) and Strategy as **behavioural** (how responsibility and algorithms are assigned). Yet the code can be byte-for-byte similar: a field of interface type, set via constructor or setter, with methods delegating to it. Many experienced engineers say "they're the same picture" — and mechanically they nearly are. The distinction is about *what the injected thing represents* and *how the design is expected to evolve*, which is what changes the decisions a maintainer makes. ## Definitions **Strategy**: define a family of interchangeable algorithms, encapsulate each, and make them substitutable so the algorithm can vary independently of the clients that use it. Participants: **Context** (holds a strategy, delegates the varying step), **Strategy** interface, **ConcreteStrategy** implementations. Example: `TextComposer` with a `LineBreaker` strategy — simple, TeX-style, or array-based. **Bridge**: decouple an abstraction from its implementation so the two can vary independently. Participants: **Abstraction**, **RefinedAbstraction**, **Implementor**, **ConcreteImplementor**. Example: `Shape`/`Circle` over `Renderer`/`VectorRenderer`. ## Six discriminators 1. **Scope of the injected object.** Strategy = one algorithm answering one question, usually a single-method interface (which is why lambdas/function values replace strategies neatly in languages that have them). Bridge implementor = a *platform*: several primitives (`drawCircle`, `drawLine`, `fill`, `flush`) which the abstraction *composes* into higher-level operations. 2. **Is there a second hierarchy?** Bridge implies an abstraction hierarchy on the other side (Circle, Square, Polygon) that would otherwise multiply against the implementors. Strategy usually has a single context class, or contexts that vary for unrelated reasons. 3. **Lifetime and swap frequency.** Strategies are commonly chosen per call, per request, or per configuration flag, and swapping mid-life is normal and expected. A bridge's implementor is normally chosen once at construction ("this document renders to PDF") and swapping it mid-life is possible but unusual. 4. **Who is complete without whom.** A Strategy Context is a meaningful, complete object with a default policy; the strategy fills a hole. A Bridge Abstraction is *incapable* of doing its job without an implementor — it has no mechanism of its own at all. 5. **What motivates the design.** Strategy is motivated by conditional logic you want to eliminate (`if (mode == FAST) ... else if (mode == ACCURATE) ...`) and by open/closed extension of one behaviour. Bridge is motivated by **combinatorial explosion** and by wanting two sides to compile/deploy/version independently. 6. **Direction of knowledge.** Both point one way, but Bridge implementors are deliberately *lower level* than the abstraction — a layering statement. Strategies sit at the *same* conceptual level as the context; they are alternative policies, not a lower platform. ## Edge cases - **A single-implementor "bridge" is really neither.** With one implementation and no second axis, you have plain dependency injection for testability. That is fine — just don't dress it up with a pattern name. - **A Strategy can appear inside a Bridge implementor.** `RasterRenderer` may take an `AntiAliasingStrategy`. Patterns nest; roles are per-relationship, not per-class. - **Some designs are honestly both.** If a `Repository` abstraction hierarchy sits over storage implementors and you also swap them per request, arguing the label is less useful than describing the constraints. Interviewers want to see you reason about scope and evolution, not that you can pick the One True Name. - **State is a third relative.** State also injects/holds an interface, but the object *changes its own reference over time* in response to events, and states often know about each other's transitions — behaviour neither Strategy nor Bridge implies. - **Language features blur it further.** With first-class functions, a one-method strategy is just a function parameter. A Bridge implementor rarely collapses to a function because it is a coherent set of primitives with its own lifecycle (open, configure, flush, close). ## How to answer in an interview Lead with "mechanically similar, different intent and scale," then give two or three discriminators (single algorithm vs whole platform; is there a second hierarchy that would explode; per-call swap vs lifetime pairing), and close by acknowledging that some designs are both and that the useful thing is naming the axes of variation, not winning a taxonomy argument.
- If you inject one interface with a single method into one class, is it a Strategy or a Bridge?Almost certainly Strategy — or just dependency injection. Bridge implies a second hierarchy on the abstraction side and an implementor exposing several primitives that the abstraction composes; neither is present with a single method and a single host class.
- How does State differ from both?State also holds an interface reference, but the object mutates that reference itself as events occur, and concrete states typically encode the transitions. Neither Strategy nor Bridge implies self-directed reassignment or knowledge of successors.
- Does it matter which label a team uses if the code is identical?It matters for expectations, not for compilation. Calling it a Bridge tells maintainers the interface is a long-lived contract two hierarchies depend on, so changes are expensive and versioned; calling it a Strategy signals a cheap, per-use policy hole that can grow freely. Wrong labels lead to the wrong change-cost assumptions.
Strategy is choosing which route the sat-nav should compute — fastest, shortest, avoid tolls — swappable mid-journey, one decision. Bridge is the fact that the whole navigation app runs over an interchangeable map provider with its own set of primitive services (geocode, tiles, traffic); you pick a provider when the app starts, and it is what makes the app able to function at all.
saying these in an interview costs you the question
- "They're identical, the distinction is meaningless" — mechanically close, but the labels set different expectations about interface stability and growth
- Calling any constructor-injected interface a Bridge
- Claiming Bridge implementors must be swappable at runtime to qualify
- Insisting every design has exactly one correct pattern name
- Confusing State with Strategy or Bridge because all three hold an interface reference