design-pattern-strategy

Skill: Strategy

Intent

Define a family of algorithms behind a common strategy contract and select among them at runtime or configuration time. This keeps client flow stable while algorithm choices evolve.

Applicability Signals

• Signal 1: Conditional branches select algorithm variants in many call sites.
• Signal 2: New algorithm variants appear regularly and must be plugged in with low disruption.
• Signal 3: Runtime environment, tenant policy, or feature flags determine algorithm choice.

Contraindications

• Case 1: Only one algorithm exists and no variation pressure is expected.
• Case 2: Variants differ by one parameter and can be handled by data/config only.
• Case 3: Strategy selection criteria are unstable and undocumented, causing hidden behavior drift.

Decision Heuristics

• If algorithm variation is the main axis of change and caller workflow should stay fixed, prefer Strategy.
• If behavior evolves through lifecycle states with explicit transitions, State may be more appropriate.
• Decision anti-bias note: avoid creating many micro-strategies for negligible differences.

Implementation Checklist

• Define strategy interface with minimal method surface.
• Implement concrete strategies for each meaningful algorithm variant.
• Inject strategy into context (constructor/setter/config factory).
• Keep selection policy separate from strategy implementation details.
• Add tests proving strategy replacement without client code changes.

Misuse Checks

• Misuse 1: Context inspects concrete strategy types → Remediation: move variant behavior behind strategy interface.
• Misuse 2: Strategies rely on shared mutable hidden globals → Remediation: inject explicit dependencies/state.
• Misuse 3: Selection logic duplicated across multiple callers → Remediation: centralize strategy factory/resolver.

Verification Rubric

• Correctness:
  • Baseline strategy yields expected output/behavior.
  • Alternate strategy can be swapped with no client workflow edits.
• Design quality:
  • Strategy contracts are cohesive and stable.
  • Selection policy is explicit and testable.
• Regression safety:
  • Tests cover at least two concrete strategies plus selection boundary case.

Language-Specific Adaptations (Optional)

• TypeScript: use generic strategy interfaces for typed input/output contracts.
• Python: strategies can be classes or callables; keep contract explicit via protocols.
• Go: use interface-based strategies and constructor injection into services.

Related Patterns (Optional)

• State: strategy chooses algorithm; state models lifecycle-dependent behavior transitions.
• Template Method: template fixes workflow skeleton; strategy swaps specific algorithm steps.

Attribution & Sources

• Source Site: Refactoring.Guru
• Source URLs:
  • https://refactoring.guru/design-patterns/strategy
  • https://refactoring.guru/design-patterns
• Derivation Note: Concepts derived from referenced sources; explanatory wording rewritten for this repository.
• Policy Note: This artifact intentionally includes no direct quotes and no Refactoring.Guru images.