When you need an object to do the same kind of task in multiple different ways, the Strategy pattern gives you a clean mechanism: define a family of algorithms, encapsulate each one in its own class, and make them interchangeable through a shared interface. The context object holds a reference to one strategy at a time and delegates the work to it. The client decides which strategy to plug in.

Why does this matter? Because the alternative is a growing pile of conditionals inside a single method. Every time a new algorithm appears, you crack open the existing class and wedge in another branch. The Strategy pattern eliminates that by letting you add new algorithms as new classes: without touching the code that uses them.

The Structure

The pattern has three participants:

Strategy interface: declares the method that all algorithms must implement.

Concrete strategies: each class implements the interface with a different algorithm.

Context: holds a reference to a strategy and delegates execution to it.

Payment Example

Consider a checkout system that supports multiple payment methods. Instead of hardcoding payment logic, you define a common interface and let each payment method implement it:

1class PaymentStrategy:
2    def pay(self, amount: float) -> str:
3        raise NotImplementedError
4
5class CreditCardStrategy(PaymentStrategy):
6    def __init__(self, card_number: str):
7        self.card_number = card_number
8
9    def pay(self, amount: float) -> str:
10        return f"Charged ${amount} to credit card {self.card_number[-4:]}"
11
12class PayPalStrategy(PaymentStrategy):
13    def __init__(self, email: str):
14        self.email = email
15
16    def pay(self, amount: float) -> str:
17        return f"Sent ${amount} via PayPal to {self.email}"
18
19class CryptoStrategy(PaymentStrategy):
20    def __init__(self, wallet_address: str):
21        self.wallet_address = wallet_address
22
23    def pay(self, amount: float) -> str:
24        return f"Transferred ${amount} in crypto to {self.wallet_address[:8]}..."

The Context Class

The context does not know or care which payment method is active. It holds a strategy reference and calls it:

1class Checkout:
2    def __init__(self, strategy: PaymentStrategy):
3        self.strategy = strategy
4
5    def set_strategy(self, strategy: PaymentStrategy):
6        self.strategy = strategy
7
8    def process_payment(self, amount: float) -> str:
9        return self.strategy.pay(amount)

The client code decides which strategy to inject:

1checkout = Checkout(CreditCardStrategy("4111-1111-1111-1234"))
2print(checkout.process_payment(99.99))
3
4checkout.set_strategy(PayPalStrategy("[email protected]"))
5print(checkout.process_payment(49.99))

The Checkout class never changes when you add a new payment method. You simply create a new class that implements PaymentStrategy and pass it in.

The Strategy pattern exists because of a specific, recurring problem: a method that branches on type to select an algorithm. Every time you see a function with if algorithm == "X" ... elif algorithm == "Y" ... elif algorithm == "Z", you are looking at a candidate for Strategy. Understanding the before-and-after transformation makes the pattern click.

The Problem: Conditional Algorithm Selection

Imagine a notification service that sends messages through different channels. The naive implementation puts all channel logic in one method:

1class NotificationService:
2    def send(self, channel: str, recipient: str, message: str):
3        if channel == "email":
4            # connect to SMTP server
5            # format HTML template
6            # send email
7            print(f"Email to {recipient}: {message}")
8        elif channel == "sms":
9            # connect to Twilio API
10            # validate phone number
11            # send SMS
12            print(f"SMS to {recipient}: {message}")
13        elif channel == "push":
14            # look up device token
15            # format push payload
16            # send via APNs/FCM
17            print(f"Push to {recipient}: {message}")

This works for three channels. But what happens when you add Slack, WhatsApp, in-app notifications, and webhook callbacks? The send method balloons. Every addition forces you to modify this class, test the entire method, and risk breaking existing channels. The notification logic for every channel lives in one place: a violation of the Single Responsibility Principle.

The Solution: Extract Each Algorithm into Its Own Class

Apply the Strategy pattern. Define an interface, move each branch into a concrete class, and let the context delegate:

1class NotificationStrategy:
2    def send(self, recipient: str, message: str):
3        raise NotImplementedError
4
5class EmailNotification(NotificationStrategy):
6    def send(self, recipient: str, message: str):
7        # connect to SMTP, format HTML, send
8        print(f"Email to {recipient}: {message}")
9
10class SmsNotification(NotificationStrategy):
11    def send(self, recipient: str, message: str):
12        # connect to Twilio, validate number, send
13        print(f"SMS to {recipient}: {message}")
14
15class PushNotification(NotificationStrategy):
16    def send(self, recipient: str, message: str):
17        # look up device token, format payload, send
18        print(f"Push to {recipient}: {message}")
19
20class NotificationService:
21    def __init__(self, strategy: NotificationStrategy):
22        self.strategy = strategy
23
24    def notify(self, recipient: str, message: str):
25        self.strategy.send(recipient, message)

Now adding Slack is a new class, SlackNotification(NotificationStrategy), with zero changes to NotificationService or any existing notification class.

What Encapsulation Buys You

Each strategy class encapsulates everything about one algorithm:

• Its own state, EmailNotification can hold SMTP credentials; SmsNotification can hold a Twilio API key. The context does not manage any of this.
• Its own tests, You write unit tests for EmailNotification in isolation. No need to set up SMS or push infrastructure to test email sending.
• Its own evolution, When the email team rewrites the HTML templating engine, they modify one class. The SMS and push teams are unaffected.

This isolation is what "encapsulate" means in the Gang of Four definition. Each algorithm is a self-contained unit that the rest of the system interacts with only through the strategy interface.

The Strategy pattern lets the client choose an algorithm. The State pattern solves a different problem: an object whose behavior changes based on its internal condition. The object does not just pick one algorithm and stick with it: it moves through a sequence of states during its lifetime, and the same method call produces different results depending on which state the object is in. To the caller, it looks like the object has changed its class.

The classic example is a vending machine. The same physical button does completely different things depending on whether the machine has a coin inserted, is currently dispensing, or is sold out. Rather than packing all those conditionals into one massive method, the State pattern delegates each behavior to a state object.

The State Interface

Every state in the vending machine implements the same interface, the set of actions a user can take:

1class VendingMachineState:
2    def insert_coin(self, machine):
3        raise NotImplementedError
4
5    def eject_coin(self, machine):
6        raise NotImplementedError
7
8    def dispense(self, machine):
9        raise NotImplementedError

Concrete States

Each state class implements these methods according to what makes sense in that state:

1class NoCoinState(VendingMachineState):
2    def insert_coin(self, machine):
3        print("Coin accepted")
4        machine.set_state(machine.has_coin_state)
5
6    def eject_coin(self, machine):
7        print("No coin to eject")
8
9    def dispense(self, machine):
10        print("Insert a coin first")
11
12class HasCoinState(VendingMachineState):
13    def insert_coin(self, machine):
14        print("Coin already inserted")
15
16    def eject_coin(self, machine):
17        print("Coin returned")
18        machine.set_state(machine.no_coin_state)
19
20    def dispense(self, machine):
21        print("Dispensing item...")
22        machine.item_count -= 1
23        if machine.item_count > 0:
24            machine.set_state(machine.no_coin_state)
25        else:
26            machine.set_state(machine.sold_out_state)
27
28class SoldOutState(VendingMachineState):
29    def insert_coin(self, machine):
30        print("Machine is sold out — coin returned")
31
32    def eject_coin(self, machine):
33        print("No coin inserted")
34
35    def dispense(self, machine):
36        print("Machine is sold out")

The Context: Vending Machine

The vending machine holds a reference to its current state and delegates all actions to it:

1class VendingMachine:
2    def __init__(self, item_count: int):
3        self.no_coin_state = NoCoinState()
4        self.has_coin_state = HasCoinState()
5        self.sold_out_state = SoldOutState()
6        self.item_count = item_count
7        self.state = self.no_coin_state if item_count > 0 else self.sold_out_state
8
9    def set_state(self, state: VendingMachineState):
10        self.state = state
11
12    def insert_coin(self):
13        self.state.insert_coin(self)
14
15    def eject_coin(self):
16        self.state.eject_coin(self)
17
18    def dispense(self):
19        self.state.dispense(self)

Notice how the VendingMachine's public methods are simple one-line delegations. All the behavioral logic lives in the state classes. When you call machine.insert_coin(), the response depends entirely on which state object is currently assigned: NoCoinState accepts the coin, HasCoinState rejects it, and SoldOutState returns it.

The real power of the State pattern is not just that behavior changes: it is that the transitions between states are explicit, traceable, and impossible to get wrong in the ways that conditional code gets wrong. Each state knows exactly which states it can transition to, and the transition happens through a clear method call rather than a reassignment of a string or enum buried in a 300-line function.

States Own Their Transitions

In the vending machine, NoCoinState.insert_coin() transitions to HasCoinState. HasCoinState.dispense() transitions to either NoCoinState or SoldOutState. Each state class declares its own exit conditions. You can read a single state class and know every possible transition out of that state without looking at any other code.

This is a dramatic improvement over the switch-statement approach:

1# Without State pattern — transitions hidden in conditionals
2class VendingMachine:
3    def insert_coin(self):
4        if self.status == "no_coin":
5            self.status = "has_coin"
6        elif self.status == "has_coin":
7            print("Already has coin")
8        elif self.status == "sold_out":
9            print("Sold out")
10        elif self.status == "dispensing":
11            print("Please wait")
12
13    def dispense(self):
14        if self.status == "has_coin":
15            self.status = "dispensing"
16            # dispense logic...
17            if self.item_count > 0:
18                self.status = "no_coin"
19            else:
20                self.status = "sold_out"
21        elif self.status == "no_coin":
22            print("Insert coin first")
23        # ... more branches

Every method contains branches for every state. Adding a new state means modifying every method. Missing one branch creates a silent bug: the machine does nothing when it should reject an action, or worse, it dispenses an item without payment.

Transition Chains

States can trigger multi-step transitions. In the vending machine, pressing dispense in HasCoinState decrements the count and immediately transitions to either NoCoinState or SoldOutState. The caller does not orchestrate this sequence: the state handles it internally.

More complex systems have longer chains. A document approval workflow might move through Draft, Review, Approved, and Published. Each state's approve() method checks permissions and either transitions to the next state or rejects the action with a reason. The caller just calls document.approve() and the current state handles everything.

Testing State Transitions

Each state class can be tested independently. To test that HasCoinState.dispense() transitions correctly, you create a mock machine, set its item count, call dispense, and verify the state was set to the expected next state. You do not need to simulate an entire user session: just test each state's behavior and transitions in isolation.

1def test_dispense_with_items_remaining():
2    machine = VendingMachine(item_count=3)
3    machine.set_state(machine.has_coin_state)
4    machine.dispense()
5    assert machine.state == machine.no_coin_state
6    assert machine.item_count == 2
7
8def test_dispense_last_item():
9    machine = VendingMachine(item_count=1)
10    machine.set_state(machine.has_coin_state)
11    machine.dispense()
12    assert machine.state == machine.sold_out_state
13    assert machine.item_count == 0

This testability is a direct consequence of the pattern's structure. Each state is a unit with clear inputs (method call + context data) and clear outputs (behavior + state transition).

If you put the class diagrams for Strategy and State side by side, they look identical. Both define an interface with multiple implementations. Both use a context object that holds a reference to the current implementation and delegates method calls to it. This structural similarity is why interviewers love asking about the difference: it tests whether you understand the patterns at a behavioral level, not just a structural one.

The Critical Difference: Who Controls the Swap?

Strategy: the client chooses. The calling code selects which algorithm to use and injects it into the context. The context does not know why it has a particular strategy and does not change it on its own. A checkout system receives a CreditCardStrategy from the UI layer because the user selected credit card payment. The checkout processes it and is done.

State: the object changes itself. The context's behavior changes because its internal state transitions during its lifecycle. No external actor tells the vending machine to switch from HasCoinState to NoCoinState: the HasCoinState.dispense() method triggers that transition internally based on the machine's data.

This distinction drives every other difference:

When to Use Which

Use Strategy when:

• The caller has the domain knowledge to select the algorithm (user picks a sort order, admin chooses an encryption method, configuration file specifies a logging format)
• The algorithm is set once and used for the duration of the operation
• The algorithms do not need to know about each other

Use State when:

• The object has a lifecycle with distinct phases (order processing, TCP connections, UI components with modes)
• Behavior must change in response to internal events, not external selection
• States need to trigger transitions to other states based on the object's data

Sometimes the boundary blurs. A text editor has a "mode" (insert, command, visual in Vim). Is that Strategy or State? It depends on implementation. If the user explicitly switches modes from the keyboard, and each mode simply handles keystrokes differently, it could be either. But if modes transition automatically (entering insert mode after pressing 'i' in command mode, returning to command mode after pressing Escape), that is State: the transitions are part of the object's behavior, not external choices.

Combining Both Patterns

Real systems often use both. A ride-sharing app might use the State pattern for trip lifecycle (Requested, DriverAssigned, InProgress, Completed) and the Strategy pattern for pricing algorithms (SurgePricing, FlatRatePricing, SubscriptionPricing). The State pattern manages what phase the trip is in. The Strategy pattern manages how the fare is calculated. Each pattern handles its own concern cleanly.