Strategy Pattern · Design Patterns

What is the Strategy pattern?

Strategy means: put each version of an algorithm in its own small class, all shaped the same way, and let the calling code pick — or swap — which one runs.

You do not write one method with a wall of if/else branches. Each “how to do it” becomes its own class. They all answer the same question, so the rest of your program does not care which one it is talking to.

Three pieces work together:

A strategy interface — the one behavior every algorithm must provide.
Several concrete strategies — each class implements that interface its own way.
A context — holds some strategy and calls it, without knowing which one.

The problem it solves

Without Strategy, picking an algorithm tends to live inside one method as a growing chain of conditionals.

def calculate_shipping_cost(order, shipping_type):
    if shipping_type == "STANDARD":
        return 5.0
    elif shipping_type == "EXPRESS":
        return 15.0 + order.weight * 0.5
    elif shipping_type == "FREE":
        return 0.0 if order.total >= 50 else 5.0
    raise ValueError("Unknown shipping type")

public double calculateShippingCost(Order order, String shippingType) {
    if (shippingType.equals("STANDARD")) {
        return 5.0;
    } else if (shippingType.equals("EXPRESS")) {
        return 15.0 + order.getWeight() * 0.5;
    } else if (shippingType.equals("FREE")) {
        return order.getTotal() >= 50 ? 0.0 : 5.0;
    }
    throw new IllegalArgumentException("Unknown shipping type");
}

func CalculateShippingCost(order Order, shippingType string) (float64, error) {
	switch shippingType {
	case "STANDARD":
		return 5.0, nil
	case "EXPRESS":
		return 15.0 + order.Weight*0.5, nil
	case "FREE":
		if order.Total >= 50 {
			return 0.0, nil
		}
		return 5.0, nil
	}
	return 0, fmt.Errorf("unknown shipping type: %s", shippingType)
}

function calculateShippingCost(order: Order, shippingType: string): number {
  if (shippingType === 'STANDARD') {
    return 5.0;
  } else if (shippingType === 'EXPRESS') {
    return 15.0 + order.weight * 0.5;
  } else if (shippingType === 'FREE') {
    return order.total >= 50 ? 0.0 : 5.0;
  }
  throw new Error('Unknown shipping type');
}

Every new shipping option means editing this same method again — and retesting every branch that was already there.

The strategy interface and concrete strategies

Each class owns exactly one algorithm and knows nothing about the others.

from abc import ABC, abstractmethod


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


class StandardShipping(ShippingStrategy):
    def calculate_cost(self, order):
        return 5.0


class ExpressShipping(ShippingStrategy):
    def calculate_cost(self, order):
        return 15.0 + order.weight * 0.5


class FreeShipping(ShippingStrategy):
    def calculate_cost(self, order):
        return 0.0 if order.total >= 50 else 5.0

public interface ShippingStrategy {
    double calculateCost(Order order);
}

public class StandardShipping implements ShippingStrategy {
    public double calculateCost(Order order) {
        return 5.0;
    }
}

public class ExpressShipping implements ShippingStrategy {
    public double calculateCost(Order order) {
        return 15.0 + order.getWeight() * 0.5;
    }
}

public class FreeShipping implements ShippingStrategy {
    public double calculateCost(Order order) {
        return order.getTotal() >= 50 ? 0.0 : 5.0;
    }
}

package shipping

type Strategy interface {
	CalculateCost(order Order) float64
}

type Standard struct{}

func (Standard) CalculateCost(order Order) float64 {
	return 5.0
}

type Express struct{}

func (Express) CalculateCost(order Order) float64 {
	return 15.0 + order.Weight*0.5
}

type Free struct{}

func (Free) CalculateCost(order Order) float64 {
	if order.Total >= 50 {
		return 0.0
	}
	return 5.0
}

interface ShippingStrategy {
  calculateCost(order: Order): number;
}

class StandardShipping implements ShippingStrategy {
  calculateCost(order: Order) {
    return 5.0;
  }
}

class ExpressShipping implements ShippingStrategy {
  calculateCost(order: Order) {
    return 15.0 + order.weight * 0.5;
  }
}

class FreeShipping implements ShippingStrategy {
  calculateCost(order: Order) {
    return order.total >= 50 ? 0.0 : 5.0;
  }
}

The context

The context does not know if it is holding a StandardShipping or an ExpressShipping. It only knows it has some strategy, and that is enough.

class ShippingCalculator:
    def __init__(self, strategy: ShippingStrategy) -> None:
        self.strategy = strategy

    def calculate(self, order) -> float:
        return self.strategy.calculate_cost(order)


# use
calculator = ShippingCalculator(StandardShipping())
calculator.calculate(order)

calculator.strategy = ExpressShipping()
calculator.calculate(order)  # same call site, different math

public class ShippingCalculator {
    private ShippingStrategy strategy;

    public ShippingCalculator(ShippingStrategy strategy) {
        this.strategy = strategy;
    }

    public void setStrategy(ShippingStrategy strategy) {
        this.strategy = strategy;
    }

    public double calculate(Order order) {
        return strategy.calculateCost(order);
    }
}

// use
ShippingCalculator calculator = new ShippingCalculator(new StandardShipping());
calculator.calculate(order);

calculator.setStrategy(new ExpressShipping());
calculator.calculate(order); // same call site, different math

type Calculator struct {
	strategy Strategy
}

func NewCalculator(strategy Strategy) *Calculator {
	return &Calculator{strategy: strategy}
}

func (c *Calculator) SetStrategy(strategy Strategy) {
	c.strategy = strategy
}

func (c *Calculator) Calculate(order Order) float64 {
	return c.strategy.CalculateCost(order)
}

// use
calculator := NewCalculator(Standard{})
calculator.Calculate(order)

calculator.SetStrategy(Express{})
calculator.Calculate(order) // same call site, different math

class ShippingCalculator {
  constructor(private strategy: ShippingStrategy) {}

  setStrategy(strategy: ShippingStrategy) {
    this.strategy = strategy;
  }

  calculate(order: Order) {
    return this.strategy.calculateCost(order);
  }
}

// use
const calculator = new ShippingCalculator(new StandardShipping());
calculator.calculate(order);

calculator.setStrategy(new ExpressShipping());
calculator.calculate(order); // same call site, different math

Picking a strategy without reintroducing if/else

Strategy removes the branching inside the algorithm. Something still has to decide which strategy to use — if that decision is also if/else, you have only moved the problem. A lookup map keeps the decision in one place instead.

STRATEGIES: dict[str, ShippingStrategy] = {
    "STANDARD": StandardShipping(),
    "EXPRESS": ExpressShipping(),
    "FREE": FreeShipping(),
}


def get_strategy(shipping_type: str) -> ShippingStrategy:
    strategy = STRATEGIES.get(shipping_type)
    if strategy is None:
        raise ValueError(f"Unknown shipping type: {shipping_type}")
    return strategy

public class ShippingStrategyFactory {
    private final Map<String, ShippingStrategy> strategies = Map.of(
        "STANDARD", new StandardShipping(),
        "EXPRESS", new ExpressShipping(),
        "FREE", new FreeShipping()
    );

    public ShippingStrategy getStrategy(String shippingType) {
        ShippingStrategy strategy = strategies.get(shippingType);
        if (strategy == null) {
            throw new IllegalArgumentException("Unknown shipping type: " + shippingType);
        }
        return strategy;
    }
}

var strategies = map[string]Strategy{
	"STANDARD": Standard{},
	"EXPRESS":  Express{},
	"FREE":     Free{},
}

func GetStrategy(shippingType string) (Strategy, error) {
	strategy, ok := strategies[shippingType]
	if !ok {
		return nil, fmt.Errorf("unknown shipping type: %s", shippingType)
	}
	return strategy, nil
}

const strategies: Record<string, ShippingStrategy> = {
  STANDARD: new StandardShipping(),
  EXPRESS: new ExpressShipping(),
  FREE: new FreeShipping(),
};

function getStrategy(shippingType: string): ShippingStrategy {
  const strategy = strategies[shippingType];
  if (!strategy) {
    throw new Error(`Unknown shipping type: ${shippingType}`);
  }
  return strategy;
}

Adding a fourth shipping option now means adding one class and one map entry. The calculator and every existing strategy stay untouched.

Strategy without a class

If a strategy is a single operation with no state of its own, you often do not need a named class at all — a plain function works, since Strategy only needs “something callable with the same shape.”

from typing import Callable

DiscountStrategy = Callable[[float], float]


class PriceCalculator:
    def __init__(self, discount: DiscountStrategy) -> None:
        self.discount = discount

    def final_price(self, price: float) -> float:
        return self.discount(price)


# use
ten_percent_off = PriceCalculator(lambda price: price * 0.90)
ten_percent_off.final_price(200.0)  # 180.0

@FunctionalInterface
public interface DiscountStrategy {
    double apply(double price);
}

public class PriceCalculator {
    private DiscountStrategy discount;

    public PriceCalculator(DiscountStrategy discount) {
        this.discount = discount;
    }

    public double finalPrice(double price) {
        return discount.apply(price);
    }
}

// use
PriceCalculator tenPercentOff = new PriceCalculator(price -> price * 0.90);
tenPercentOff.finalPrice(200.0); // 180.0

type DiscountStrategy func(price float64) float64

type PriceCalculator struct {
	discount DiscountStrategy
}

func NewPriceCalculator(discount DiscountStrategy) *PriceCalculator {
	return &PriceCalculator{discount: discount}
}

func (p *PriceCalculator) FinalPrice(price float64) float64 {
	return p.discount(price)
}

// use
tenPercentOff := NewPriceCalculator(func(price float64) float64 {
	return price * 0.90
})
tenPercentOff.FinalPrice(200.0) // 180.0

type DiscountStrategy = (price: number) => number;

class PriceCalculator {
  constructor(private discount: DiscountStrategy) {}

  finalPrice(price: number) {
    return this.discount(price);
  }
}

// use
const tenPercentOff = new PriceCalculator((price) => price * 0.9);
tenPercentOff.finalPrice(200.0); // 180

This is still Strategy — an interface-shaped thing, several implementations, a context that delegates — just without a class per algorithm. Reach for a full class once a strategy needs its own fields or several methods.

Worked example: customer discount engine

A pricing engine that applies a different discount depending on a customer’s membership tier.

class DiscountStrategy(ABC):
    @abstractmethod
    def apply_discount(self, amount: float) -> float: ...


class RegularCustomerDiscount(DiscountStrategy):
    def apply_discount(self, amount):
        return amount  # no discount


class SilverCustomerDiscount(DiscountStrategy):
    def apply_discount(self, amount):
        return amount * 0.95  # 5% off


class GoldCustomerDiscount(DiscountStrategy):
    def apply_discount(self, amount):
        return amount * 0.85  # 15% off


class PricingEngine:
    def __init__(self, discount_strategy: DiscountStrategy) -> None:
        self.discount_strategy = discount_strategy

    def calculate_final_price(self, amount: float) -> float:
        return self.discount_strategy.apply_discount(amount)


# use
strategies = {
    "gold": GoldCustomerDiscount(),
    "silver": SilverCustomerDiscount(),
}
strategy = strategies.get(customer.tier, RegularCustomerDiscount())

engine = PricingEngine(strategy)
total = engine.calculate_final_price(order.subtotal)

public interface DiscountStrategy {
    double applyDiscount(double amount);
}

public class RegularCustomerDiscount implements DiscountStrategy {
    public double applyDiscount(double amount) {
        return amount; // no discount
    }
}

public class SilverCustomerDiscount implements DiscountStrategy {
    public double applyDiscount(double amount) {
        return amount * 0.95; // 5% off
    }
}

public class GoldCustomerDiscount implements DiscountStrategy {
    public double applyDiscount(double amount) {
        return amount * 0.85; // 15% off
    }
}

public class PricingEngine {
    private DiscountStrategy discountStrategy;

    public PricingEngine(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }

    public double calculateFinalPrice(double amount) {
        return discountStrategy.applyDiscount(amount);
    }
}

// use
DiscountStrategy strategy = switch (customer.getTier()) {
    case GOLD -> new GoldCustomerDiscount();
    case SILVER -> new SilverCustomerDiscount();
    default -> new RegularCustomerDiscount();
};

PricingEngine engine = new PricingEngine(strategy);
double total = engine.calculateFinalPrice(order.getSubtotal());

type DiscountStrategy interface {
	ApplyDiscount(amount float64) float64
}

type RegularDiscount struct{}

func (RegularDiscount) ApplyDiscount(amount float64) float64 {
	return amount // no discount
}

type SilverDiscount struct{}

func (SilverDiscount) ApplyDiscount(amount float64) float64 {
	return amount * 0.95 // 5% off
}

type GoldDiscount struct{}

func (GoldDiscount) ApplyDiscount(amount float64) float64 {
	return amount * 0.85 // 15% off
}

type PricingEngine struct {
	discount DiscountStrategy
}

func NewPricingEngine(discount DiscountStrategy) *PricingEngine {
	return &PricingEngine{discount: discount}
}

func (p *PricingEngine) CalculateFinalPrice(amount float64) float64 {
	return p.discount.ApplyDiscount(amount)
}

// use
var strategy DiscountStrategy = RegularDiscount{}
switch customer.Tier {
case "gold":
	strategy = GoldDiscount{}
case "silver":
	strategy = SilverDiscount{}
}

engine := NewPricingEngine(strategy)
total := engine.CalculateFinalPrice(order.Subtotal)

interface DiscountStrategy {
  applyDiscount(amount: number): number;
}

class RegularCustomerDiscount implements DiscountStrategy {
  applyDiscount(amount: number) {
    return amount; // no discount
  }
}

class SilverCustomerDiscount implements DiscountStrategy {
  applyDiscount(amount: number) {
    return amount * 0.95; // 5% off
  }
}

class GoldCustomerDiscount implements DiscountStrategy {
  applyDiscount(amount: number) {
    return amount * 0.85; // 15% off
  }
}

class PricingEngine {
  constructor(private discountStrategy: DiscountStrategy) {}

  calculateFinalPrice(amount: number) {
    return this.discountStrategy.applyDiscount(amount);
  }
}

// use
const strategies: Record<string, DiscountStrategy> = {
  gold: new GoldCustomerDiscount(),
  silver: new SilverCustomerDiscount(),
};
const strategy = strategies[customer.tier] ?? new RegularCustomerDiscount();

const engine = new PricingEngine(strategy);
const total = engine.calculateFinalPrice(order.subtotal);

If a “Platinum” tier appears next quarter, you write one new discount class. PricingEngine never changes, and neither does any existing discount class.

When it helps

Use Strategy whenever a task can be done in more than one way, and the choice of which way needs to change independently of the code that requests the result — sorting, payment methods, pricing rules, validation rules, compression formats.

It pays off anywhere you would otherwise write a long if/else or switch chain over a type, where each branch is really its own self-contained piece of logic.

When it hurts

If there is genuinely only one way to do the task, or the algorithm is a one-line calculation, Strategy adds an interface and a class for no real benefit. A private helper function reads better.

Strategy also does not remove decision-making by itself — it only relocates it. If you replace an if/else chain inside an algorithm with an if/else chain that picks which strategy to construct, you kept the exact problem you were trying to avoid. That is why a map, factory, or dependency injection usually accompanies Strategy.

Practical tips

Define the strategy as an interface, or a plain function type if it is a single operation with no state.
Keep strategies stateless when you can — a strategy that is a pure function is easy to reuse, test, and share.
Let a map or factory choose the concrete strategy. Do not let the caller construct the concrete class directly.
Document what distinguishes each strategy (cost, speed, accuracy) so a future reader knows why more than one exists.

Check your understanding

Strategy in one line?
A family of interchangeable algorithms behind one interface.

What problem does it remove?
Long if/else or switch chains where each branch is really a distinct algorithm.

Does Strategy remove the need to choose an algorithm?
No — it moves that choice into a separate place, often a map or factory.

How is Strategy different from Factory?
Factory creates the right object. Strategy chooses the right algorithm for a task the context runs.

When should you skip it?
When there is only one way to do the task, or the algorithm is trivial.

What to learn next

Next: Observer Pattern — how one object can automatically notify many others when something changes.