creational
Strategy
Define a family of algorithms, encapsulate each one, and make them interchangeable.
There are usually several ways to do one job — sort, compress, route, or charge a payment — and you want to choose among them without burying a sprawling if/else or switch in your business logic. That kind of conditional is a classic code smell: every new variant reopens the same method, and the selection logic tangles with the work itself. Strategy pulls each algorithm into its own class behind a common interface so they become interchangeable parts.
GPS navigation — pick fastest route, shortest route, or avoid tolls. The app delegates to whichever strategy you chose.
Key Concepts
1
You define a strategy interface that captures the operation, then implement one class per algorithm. A context class holds a reference to a strategy and delegates the work to it, never knowing or caring which concrete strategy it has. Because the strategy is just a field, it can be injected at construction or swapped at runtime — a shopping cart can switch from a credit-card strategy to a PayPal strategy between two checkouts. In languages with first-class functions, a simple lambda often stands in for a full strategy class, which is why Comparator arguments and pluggable callbacks are Strategy in everyday clothing.
Comparator
2
Use it for interchangeable sorting or compression algorithms, payment methods, pricing and discount rules, or routing policies — anywhere behaviour legitimately varies and you want that variation to be open for extension. The contrast examiners look for is with State: both inject behaviour through composition, but Strategy's algorithms are independent and chosen by the client, while State's behaviours know about each other and drive transitions. The minor cost is the extra classes and the fact that the client must understand the available strategies well enough to pick one.