Strategy
You'll learn to
- -Swap an algorithm or policy (payment method, sorting comparator, pricing rule) at runtime behind a common interface
- -Explain how Strategy directly satisfies the Open/Closed Principle for behavior that changes independently of its caller
Strategy defines a family of interchangeable algorithms, encapsulates each one behind a common interface, and lets the algorithm vary independently from the client that uses it. It is, in practice, the single most commonly applied pattern across LLD interviews, because "this behavior needs to vary" is one of the most common shapes a requirement takes.
The Canonical Shape
class PricingStrategy(ABC):
@abstractmethod
def calculate(self, base_price: float) -> float: ...
class RegularPricing(PricingStrategy):
def calculate(self, base_price: float) -> float: return base_price
class MemberDiscountPricing(PricingStrategy):
def calculate(self, base_price: float) -> float: return base_price * 0.9
class HolidaySalePricing(PricingStrategy):
def calculate(self, base_price: float) -> float: return base_price * 0.7
class Order:
def __init__(self, pricing_strategy: PricingStrategy):
self._pricing_strategy = pricing_strategy # injected, swappable
def total(self, base_price: float) -> float:
return self._pricing_strategy.calculate(base_price)
# swap the pricing rule at runtime, or per-order, with zero change to Order
Order(HolidaySalePricing()).total(100.0) # 70.0This Is How Open/Closed Actually Gets Satisfied
Recall the growing if/elif chain from the Open/Closed Principle chapter - Strategy is the concrete mechanism that closes that gap. Order never branches on pricing type; it just calls calculate() on whatever strategy it was given. Adding a new pricing rule (BlackFridayPricing) means writing one new class, with zero changes to Order and zero risk of breaking existing pricing rules.
Strategy vs. State (Preview)
Strategy and State (a later chapter) look structurally almost identical - both hold a reference to an interface and delegate to it. The distinction is about who decides which implementation is active and why: with Strategy, the client explicitly chooses and passes in the algorithm (a caller picks HolidaySalePricing because it is currently a holiday). With State, the object switches its own internal state based on its own behavior, without the client ever choosing directly. Keep this distinction in mind - it resolves a lot of interview ambiguity when a design could plausibly be read as either.
A fast interview identification test: if you find yourself designing an interface where "the caller passes in which behavior to use," that is Strategy. If the object itself decides to switch behavior based on internal events, look at State instead.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.