I. Strategy — Behavioral Pattern

Strategy defines a family of interchangeable algorithms, encapsulates each one behind a common interface, and lets the client swap between them at runtime. The object that uses the algorithm — the Context — never hard-codes which one it's running; it just delegates to whichever strategy it currently holds.

This solves the problem of algorithm-specific branching creeping into business logic. Without Strategy, adding a new pricing rule usually means adding another if/switch branch inside the checkout code itself, which grows harder to test and more error-prone with every new rule. Strategy moves each algorithm into its own type, so the checkout code stays a single, unchanging delegation call.

It's the same shape as sorting with a custom comparator, or picking a compression algorithm at runtime — the caller stays generic, the algorithm is swappable.

II. Real-world Example

A coffee shop checkout where the pricing rule depends on the type of customer:

1. Checkout (Context) — holds a PricingStrategy and exposes Total(basePrice) and SetStrategy(strategy). It has no idea what "Happy Hour" or "VIP" actually means.

2. PricingStrategy (interface) — declares Calculate(basePrice float64) float64 and Name() string, the contract every pricing rule must implement.

3. RegularPricing — charges full price.

4. HappyHourPricing — applies a 20% discount.

5. VIPPricing — applies a 30% discount.

Swapping strategies at runtime via SetStrategy changes Checkout's behavior without touching its code.

III. Implementation

pricing_strategy.go

1package strategy
2
3type PricingStrategy interface {
4	Calculate(basePrice float64) float64
5	Name() string
6}

checkout.go

1package strategy
2
3type Checkout struct {
4	strategy PricingStrategy
5}
6
7func NewCheckout(strategy PricingStrategy) *Checkout {
8	return &Checkout{strategy: strategy}
9}
10
11func (c *Checkout) SetStrategy(strategy PricingStrategy) {
12	c.strategy = strategy
13}
14
15func (c *Checkout) Total(basePrice float64) float64 {
16	return c.strategy.Calculate(basePrice)
17}
18
19func (c *Checkout) StrategyName() string {
20	return c.strategy.Name()
21}

regular_pricing.go

1package strategy
2
3type RegularPricing struct{}
4
5func (RegularPricing) Calculate(basePrice float64) float64 {
6	return basePrice
7}
8
9func (RegularPricing) Name() string {
10	return "Regular"
11}

happy_hour_pricing.go

1package strategy
2
3type HappyHourPricing struct{}
4
5func (HappyHourPricing) Calculate(basePrice float64) float64 {
6	return basePrice * 0.8
7}
8
9func (HappyHourPricing) Name() string {
10	return "Happy Hour"
11}

vip_pricing.go

1package strategy
2
3type VIPPricing struct{}
4
5func (VIPPricing) Calculate(basePrice float64) float64 {
6	return basePrice * 0.7
7}
8
9func (VIPPricing) Name() string {
10	return "VIP"
11}

main.go (usage)

1checkout := strategy.NewCheckout(strategy.RegularPricing{})
2basePrice := 5.0
3fmt.Printf("Regular total: %.2f (%s)\n", checkout.Total(basePrice), checkout.StrategyName())
4
5checkout.SetStrategy(strategy.HappyHourPricing{})
6fmt.Printf("Happy hour total: %.2f (%s)\n", checkout.Total(basePrice), checkout.StrategyName())
7
8checkout.SetStrategy(strategy.VIPPricing{})
9fmt.Printf("VIP total: %.2f (%s)\n", checkout.Total(basePrice), checkout.StrategyName())

IV. Explain the example above

1. strategy.NewCheckout(strategy.RegularPricing{}) creates a Checkout whose current strategy is RegularPricing.

2. checkout.Total(5.0) delegates to RegularPricing.Calculate(5.0), which simply returns 5.0 unchanged.

3. checkout.SetStrategy(strategy.HappyHourPricing{}) swaps the internal strategy pointer — Checkout's own code doesn't change at all.

4. checkout.Total(5.0) now delegates to HappyHourPricing.Calculate(5.0), returning 5.0 * 0.8 = 4.0.

5. checkout.SetStrategy(strategy.VIPPricing{}) swaps again, and checkout.Total(5.0) now returns 5.0 * 0.7 = 3.5.

Running it produces:

1*** Example Strategy ***
2Regular total: 5.00 (Regular)
3Happy hour total: 4.00 (Happy Hour)
4VIP total: 3.50 (VIP)
5*** End of Strategy ***

The same basePrice produces three different totals, and Checkout.Total never branches on which pricing rule is active — it just calls c.strategy.Calculate(basePrice). Adding a new pricing tier means adding a new type that implements PricingStrategy, not editing Checkout.

V. Conclusion

Strategy is a good fit whenever a piece of behavior has multiple valid implementations that need to be selected or swapped at runtime, and you want that selection logic kept out of the code that uses the behavior. It keeps the Context small and stable while the family of algorithms can grow independently.

The trade-off is one more layer of indirection and one more type per algorithm — for two straightforward variants that never change, an if/else inside the Context is often more readable than a full interface plus multiple structs. Strategy earns its keep once the number of variants grows, or when the choice of algorithm needs to be injected from outside (config, user tier, feature flag) rather than hard-coded.

No pattern is universally superior.

VI. References

• Go Design Patterns (Mario Castro Contreras)

• Source code on GitHub