The Strategy Pattern

archetype Military Command → Object-Oriented Design

What It Brings

Strategy is a general’s art: choosing among alternative plans of action based on terrain, enemy disposition, available forces, and objectives. The GoF Strategy pattern maps this onto software: a family of algorithms is encapsulated in interchangeable objects, and the client selects which one to deploy at runtime. The military metaphor frames algorithm selection as tactical decision-making — you don’t hardcode your approach, you choose the right plan for the situation.

Key structural parallels:

Strategies are interchangeable plans for the same objective — a general might achieve a river crossing through direct assault, flanking maneuver, or bridge construction. Each strategy achieves the same goal through different means. The pattern encapsulates alternative algorithms behind a common interface. The metaphor makes substitutability feel like tactical flexibility rather than mere polymorphism.
Strategy selection depends on context — the right battle plan depends on terrain, weather, and enemy strength. The right algorithm depends on data characteristics, performance requirements, and resource constraints. The metaphor frames runtime algorithm selection as situational awareness rather than configuration.
Strategies are chosen by a commander, not by the troops — the general picks the strategy; the soldiers execute it. The context object selects the strategy; the strategy object performs the algorithm. The metaphor clarifies the separation of concerns: deciding what to do is distinct from doing it.
Strategies can be changed mid-campaign — generals adapt their plans as conditions change. The pattern allows the strategy to be swapped at runtime. The military metaphor makes dynamic reconfiguration feel like adaptive leadership rather than unstable code.
Each strategy encapsulates specialized knowledge — a flanking maneuver requires different expertise than a siege. Each strategy object encapsulates the specific algorithm and its internal logic. The metaphor frames encapsulation as specialization — each strategy is a domain expert.

Where It Breaks

Military strategies involve uncertainty and adaptation; algorithms are deterministic — a real battle plan rarely survives first contact with the enemy. Generals improvise, adjust, and retreat. A sorting algorithm does exactly what it’s told, every time. The metaphor imports unpredictability and judgment where the pattern delivers mechanical execution.
Strategy implies high stakes; the pattern is often trivial — in warfare, choosing the wrong strategy means casualties. In software, choosing the wrong sorting algorithm means slower performance. The military gravitas of “strategy” can make mundane algorithm selection feel more consequential than it is. Picking between bubble sort and quicksort is not D-Day.
Strategies in war interact with an opponent; algorithms don’t — military strategy is fundamentally adversarial: the enemy is actively trying to counter your plan. Most software algorithms operate on passive data. The metaphor imports adversarial thinking where the “opponent” is just input data that isn’t fighting back.
The metaphor obscures the pattern’s structural similarity to State — Strategy and State are nearly identical in implementation (both delegate to interchangeable objects behind a common interface). The military metaphor makes Strategy feel fundamentally different from State, when mechanically they are the same pattern with different intent. The vivid source domain creates a false sense of distinctiveness.
“Strategy” suggests long-term planning; the pattern is often immediate — military strategy unfolds over weeks or months. A Strategy object is typically selected and executed within a single method call. The metaphor’s temporal scale is orders of magnitude larger than the pattern’s actual operation.
Real strategies have side effects and costs; algorithms have complexity — a military strategy might sacrifice a battalion to hold a hill. The pattern’s “cost” is measured in time and space complexity. The metaphor’s human dimension — sacrifice, morale, political consequences — is entirely absent.

Expressions

“Choose a strategy” — selecting an algorithm, framing configuration as tactical decision-making
“Swap strategies at runtime” — changing algorithms dynamically, adapting the battle plan to new conditions
“Strategy pattern eliminates conditionals” — the refactoring pitch, replacing if/else chains with polymorphic strategies
“Inject a strategy” — providing an algorithm via dependency injection, assigning a battle plan to a unit
“The strategy decides how to…” — delegating algorithmic choice, treating the algorithm as a decision-maker with agency
“Family of algorithms” — the GoF description, strategies as a related set of tactical options

Origin Story

The word “strategy” comes from the Greek strategia (“office of a general”), from strategos (“general”), itself from stratos (“army”) and agein (“to lead”). The GoF Strategy pattern (1994) chose this name to capture the idea of selecting among alternative approaches to achieve the same objective. The military origin is still active in developer discourse — people speak of “choosing a strategy” and “deploying” algorithms in ways that echo tactical planning. But the pattern’s most common uses (sorting strategies, validation strategies, pricing strategies) have drifted far from the battlefield. “Strategy” in business and game theory has softened the military edge, and many developers encounter the word first in non-military contexts.

References

Gamma, E. et al. Design Patterns: Elements of Reusable Object- Oriented Software (1994), Chapter 5: Behavioral Patterns
Sun Tzu. The Art of War (5th century BC) — the archetypal text on strategic thinking that the pattern name distantly echoes
Fowler, M. “Replace Conditional with Polymorphism” — the refactoring that often leads to the Strategy pattern