How is Strategy different from State?

Structurally they look alike, but Strategy is about a client choosing among interchangeable algorithms for one operation, while State models an object whose behavior changes automatically as its own internal state transitions, often with the state objects themselves managing transitions.

Can Strategy be implemented without classes?

Yes — in languages with first-class functions, a 'strategy' can simply be a function or closure passed as a parameter, achieving the same runtime-swappable-behavior benefit without defining a formal interface and multiple classes.

Why use Strategy instead of a big switch statement?

A switch statement centralizes all algorithm variants in one place that must be edited every time a new variant is added, violating the open/closed principle; Strategy lets new algorithms be added as new classes/functions without touching existing code.

Does Strategy add runtime overhead?

There is a small amount of indirection from the virtual dispatch or function call to the strategy, but this is typically negligible compared to the benefits of decoupling and testability, except in extremely performance-critical hot loops.

Is Strategy used in standard libraries?

Yes — for example, passing a custom comparator function to a sort function, or passing a key function to a grouping utility, are everyday applications of the Strategy pattern even when developers don't name it explicitly.

Programming

Strategy Pattern

BeginnerTechnique11.5K learners

The Strategy pattern is a behavioral design pattern that defines a family of interchangeable algorithms, encapsulates each one behind a common interface, and lets a client select or swap the algorithm at runtime.

#StrategyPattern #Programming#Technique#Beginner#FactoryPattern #DesignPatterns #DependencyInjection #ObserverPattern #SoftwareDevelopment#Glossary#SkillVeris

Definition

Overview

The Strategy pattern, one of the Gang of Four's behavioral patterns, addresses the problem of having multiple ways to perform a task — say, different sorting algorithms, different pricing rules, or different compression methods — where the choice needs to vary independently of the code that uses it. Rather than embedding conditional logic (a long if/else or switch statement) that selects behavior inline, Strategy extracts each algorithm into its own class implementing a shared interface, and the context object that needs the behavior holds a reference to a strategy object, delegating the actual work to it. This achieves the 'open/closed principle': new strategies can be added by writing a new class implementing the interface, without modifying the context class or any existing strategy. It also makes each algorithm independently testable in isolation, since strategies have no dependency on the context that uses them beyond the shared interface's inputs and outputs. The strategy in use can be chosen at construction time, injected via a setter, or selected dynamically at runtime based on configuration, user input, or context. Strategy is closely related to, and often confused with, the State pattern — structurally they look similar (a context holding a reference to an interchangeable object), but their intents differ: State models an object whose internal behavior changes with its own lifecycle and typically manages its own transitions, while Strategy is about the client actively choosing among interchangeable algorithms for a single operation. Strategy is also a foundational building block for higher-order-function-friendly languages: in languages with first-class functions (JavaScript, Python, Go, Rust closures), the 'strategy' is often just a function or closure passed as an argument, rather than a full class hierarchy, achieving the same decoupling with less ceremony. Common real-world applications include payment-processing systems that support multiple payment methods, sorting or comparison logic that varies by field, validation rule sets, and route-planning algorithms that can be swapped (shortest path vs. fastest route vs. avoid tolls).

Key Concepts

Encapsulates interchangeable algorithms behind a common interface
Lets the algorithm used by a context object be selected or swapped at runtime
Replaces long conditional (if/else or switch) logic for algorithm selection
Supports the open/closed principle — new strategies added without modifying existing code
Each strategy is independently testable in isolation
Often implemented with plain functions/closures in languages with first-class functions
Structurally similar to, but conceptually distinct from, the State pattern
Commonly configured via constructor injection, setters, or runtime configuration

Use Cases

Supporting multiple payment methods or pricing strategies in checkout systems

Swapping sorting or comparison algorithms based on data type or user preference

Selecting different validation rule sets for different input contexts

Route-planning or navigation systems offering multiple path-finding strategies

Compression, encoding, or serialization systems supporting multiple formats

Machine learning pipelines that can swap different models or preprocessing strategies

Frequently Asked Questions

From the Blog

Career Growth

Mastering the Technical Interview

Technical interviews have a structure you can learn. This guide covers coding rounds (DSA patterns, LeetCode strategy), system design interviews (how to approach open- ended architecture questions), and behavioural rounds (the STAR method), plus offer negotiation.