Strategy Pattern
Strategy: start from the problem
See the responsibilities
A shipping estimator supports pickup and courier delivery. A growing conditional inside checkout mixes algorithm choices with the workflow that consumes their result.
This is a behavioral pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Strategy addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Strategy places interchangeable algorithms behind a shared contract. A context uses a chosen strategy without embedding every implementation. The caller or policy selects the strategy; that selection must still be valid for the current operation.
Checkout in our example receives a shipping-price function. The same checkout function can use pickup or courier pricing. Functions are enough for this small example; a hierarchy of classes is not required.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const pickup = subtotal => 0;
const courier = subtotal => subtotal >= 100 ? 0 : 8;
function total(subtotal, shipping) { return subtotal + shipping(subtotal); }
console.log(total(40, pickup));
console.log(total(40, courier));Expected output
40
48Choose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when a meaningful algorithm varies and consumers can rely on a shared input/output contract. It also makes each algorithm testable in isolation.
Too many tiny strategies can obscure simple logic. Validate whether a strategy applies to the user, region or operation rather than accepting arbitrary client-selected discounts. Shared signatures do not guarantee compatible units or side effects.
Distinguish the neighbouring patterns
State changes behaviour according to an object’s lifecycle state, often through transitions. Bridge separates two extension dimensions. Strategy typically changes a selected algorithm.
Follow behaviour driven by lifecycle state, two independent variation dimensions, choosing from explicit requirements to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Strategy, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside choosing from explicit requirements.
Reaching the recap and completing the quizzes are separate milestones.