The Runtime Theory
Design Patterns

Design Patterns as Named Tradeoffs

A design pattern names a recurring structure for solving a family of design problems.

The Runtime Theory Team5 min read#design-patterns#abstraction#testing
▸ On this page

The model

A design pattern names a recurring structure for solving a family of design problems. It is useful when it communicates roles and tradeoffs faster than a bespoke explanation. A pattern is not a rule to apply whenever its name sounds familiar.

A concrete walk-through

The Strategy pattern lets a caller choose among interchangeable algorithms behind a common interface. For example, a shipping quote service can select a carrier strategy based on destination and package characteristics. Tests can exercise each strategy independently and verify the selection policy separately.

Costs and failure cases

An abstraction becomes costly when it hides one simple behavior behind many interfaces or forces callers to understand irrelevant extension points. Prefer the smallest seam that supports a real variation. Patterns can guide a design review, but local constraints decide whether their structure helps.

Check your understanding

You have two pricing rules and expect a third soon. Compare a conditional statement with a strategy interface, identifying what new requirement would make the interface worthwhile.

Further reading

Refactoring.Guru: Strategy Pattern

Not started

Sign in to save your learning progress.

Sign in to save