Strategy Pattern

Description

Strategy is the behavioral pattern for interchangeable ways of doing one job: each variant of an algorithm - a pricing rule, a shipping calculation, a sort order - lives behind a shared interface, and the code that needs the result just calls whichever one it was given. You already use it every time you pass a Comparator or a key= function. This skill covers the pattern, how it replaces if chains, and where the "which strategy?" decision should live.

Shipping cost depends on the carrier the customer picks:

double shippingCost(Order order, String carrier) {
    if (carrier.equals("STANDARD")) return 5 + 1.5 * order.weightKg();
    else if (carrier.equals("EXPRESS")) return 15 + 3 * order.weightKg();
    else if (carrier.equals("PICKUP")) return 0;
    // a new carrier means editing this method... again
    throw new IllegalArgumentException(carrier);
}

def shipping_cost(order: Order, carrier: str) -> float:
    if carrier == "STANDARD":
        return 5 + 1.5 * order.weight_kg
    elif carrier == "EXPRESS":
        return 15 + 3 * order.weight_kg
    elif carrier == "PICKUP":
        return 0
    # a new carrier means editing this function... again
    raise ValueError(carrier)

Every new carrier edits the same method, the branches can't be tested in isolation, and the same if chain tends to get copied wherever carriers matter.

We'll go from simple to more technical:

1. The pattern: a strategy interface, its implementations, and the context that uses one.
2. Applying it, step by step - and strategies as lambdas and functions.
3. Where you'll see it: comparators, pricing rules, password encoders.
4. Choosing the strategy, sharing strategies safely, and Strategy versus State.

The pattern

Strategy puts each variant of an algorithm in its own class behind a shared interface. The code that needs the result (the context) holds a strategy and calls it, without knowing which one it has.

interface ShippingStrategy {
    double cost(Order order);
}

class StandardShipping implements ShippingStrategy {
    public double cost(Order o) { return 5 + 1.5 * o.weightKg(); }
}

class ExpressShipping implements ShippingStrategy {
    public double cost(Order o) { return 15 + 3 * o.weightKg(); }
}

class Checkout {
    private ShippingStrategy shipping;
    void setShipping(ShippingStrategy s) { this.shipping = s; }   // swap at runtime
    double total(Order o) { return o.itemsTotal() + shipping.cost(o); }
}

from abc import ABC, abstractmethod


class ShippingStrategy(ABC):
    @abstractmethod
    def cost(self, order: Order) -> float: ...


class StandardShipping(ShippingStrategy):
    def cost(self, o: Order) -> float:
        return 5 + 1.5 * o.weight_kg


class ExpressShipping(ShippingStrategy):
    def cost(self, o: Order) -> float:
        return 15 + 3 * o.weight_kg


class Checkout:
    def __init__(self, shipping: ShippingStrategy):
        self.shipping = shipping          # swap at runtime by assigning another

    def total(self, o: Order) -> float:
        return o.items_total + self.shipping.cost(o)

In modern Java a strategy interface with one method can also be a lambda: checkout.setShipping(o -> 0.0); for store pickup. In Python that's the usual form: a one-method strategy is just a function, Callable[[Order], float] - checkout.shipping = lambda o: 0.0 - and a registry is a dict from carrier name to function.

How it works, step by step

1. Identify the part that varies (how shipping is priced).
2. Put it behind an interface with one clear method.
3. Write one small class (or lambda) per variant.
4. The context receives a strategy - through its constructor, a setter, or a lookup map - and just calls it.
5. A new variant is a new class; nothing else changes.

Where you'll see it

• Comparator is the everyday example: list.sort(Comparator.comparing(Employee::salary)) passes a sorting strategy. In Python it's the key function: employees.sort(key=attrgetter("salary")).
• Discount and pricing rules, tax calculations per country, retry/backoff policies, compression or encryption algorithms.
• Spring picks between strategies constantly - for example different PasswordEncoder implementations behind one interface.

Choosing among the behavioral patterns

Common mistakes

Check yourself

Try to answer before opening each one - recalling beats re-reading.

1. After refactoring to Strategy, where should the "which strategy?" decision live?

2. Your "strategies" start replacing themselves as events arrive. What are you really building?

3. You have exactly two variants that will never change. Do they need a strategy interface?

Key takeaways

• Each variant of an algorithm lives in its own class (or lambda) behind one interface.
• The context calls the strategy without knowing which one it has, and it can be swapped at runtime.
• New variants are new classes - existing code stays closed for modification.
• Keep the "which strategy?" decision in one place, such as a registry map.
• Comparator is Strategy you already use every day (in Python, the key= function you pass to sorted).