Strategy Pattern Explained

Replace complex conditionals with interchangeable algorithm objects — selecting behavior at runtime through a clean, extensible interface.

Strategy Pattern

The Strategy pattern is a behavioral design pattern that defines a family of interchangeable algorithms, encapsulates each one in a separate class, and allows the algorithm to be selected at runtime.

Explanation

The Strategy pattern eliminates complex conditional logic by replacing if/else or switch chains with polymorphism. Instead of embedding multiple algorithms in one class and selecting among them with conditionals, each algorithm is encapsulated in its own class implementing a common interface. The context object holds a reference to a strategy and delegates behavior to it. Real-world examples include payment processing (selecting Stripe, PayPal, or bank transfer strategies), sorting algorithms (choosing quicksort, mergesort, or heapsort based on data characteristics), compression formats (zip, gzip, or brotli), and notification channels (email, SMS, or push). The calling code works with the strategy interface without knowing which concrete strategy is active. Strategy is closely related to dependency injection: both involve providing implementations from outside. The difference is that Strategy is about swapping algorithms at runtime, while DI is about providing dependencies at construction time.

Bookuvai Implementation

Bookuvai applies the Strategy pattern for payment processing, notification delivery, file storage (S3, local, GCS), and pricing calculation. Strategies are injected via DI and can be swapped through configuration without code changes, enabling rapid integration of new providers.

Key Facts

  • Encapsulates interchangeable algorithms behind a common interface
  • Eliminates complex if/else chains with polymorphism
  • Algorithms can be swapped at runtime without modifying calling code
  • Common uses: payment processing, sorting, compression, notifications
  • Related to dependency injection but focused on runtime algorithm selection

Related Terms

Frequently Asked Questions

How is Strategy different from the Template Method pattern?
Strategy uses composition — the algorithm is a separate object injected into the context. Template Method uses inheritance — the algorithm skeleton is defined in a base class with steps overridden by subclasses. Strategy is more flexible because strategies can be swapped at runtime.
Can I implement Strategy with functions instead of classes?
Absolutely. In functional languages and modern JavaScript/TypeScript, a strategy can be a simple function. Instead of a strategy class with an execute method, pass a function directly. This is simpler when strategies are stateless.
When should I use Strategy vs if/else?
Use Strategy when you have three or more algorithms, when new algorithms are added frequently, or when the algorithm selection logic is complex. For two simple cases that rarely change, an if/else is clearer and simpler.