Use design patterns only when pressure earns them

Interview decision

Name a pattern only after identifying the concrete change force or mismatch it solves and the cost it introduces.

Mental modelPatterns are vocabulary for earned boundaries, not ingredients in a correct answer.

Use it to

Strategy for genuinely variable dispatch or pricing policy.
Adapter for a provider contract mismatch.
State objects only when state-specific behavior outgrows guarded transitions.

Keep out of scope

Covering the Gang of Four catalog.
Predicting speculative extension points.

See the responsibility boundary

A notification sender begins as one direct channel; email and SMS provider mismatches later earn adapters, while variable selection policy may earn Strategy.

Interface sketchTypeScript

interface PricingPolicy {
  fee(ticket: ClosedTicket, at: Instant): Money;
}
// Keep one FeeCalculator until pricing truly varies.

Pattern follows pressure or problem

A pattern is a compact name for a recurring design pressure. Start with the pressure - varying policy, external mismatch, state-dependent behavior, notification fan-out, or deferred work - then choose the smallest useful shape.

Concrete example

Use Strategy for pricing rules that vary by vehicle or day; keep a single FeeCalculator method when there is only one stable rule.

Interviewer follow-ups

What concrete variation makes this useful?
What stays simpler if we do not add it yet?

Do not over-engineer: Do not award yourself a Factory, Observer, and Repository for every interview prompt.

Choose a pattern from its boundary

Strategy isolates replaceable policy; Factory centralizes complex or conditional construction; Observer separates subscribers from an event source; State gives state-dependent behavior a home; Adapter translates an external contract; Command represents deferred or auditable work; Repository hides a meaningful persistence boundary; dependency injection makes collaborators explicit.

Concrete example

A delivery workflow uses an Adapter for a carrier API and a Strategy for routing. It does not need Observer unless multiple independent reactions must occur after status changes.

Interviewer follow-ups

Which behavior varies independently?
Is this an external contract or a local policy?

Do not over-engineer: Do not force every object through a factory just because objects are constructed.

Refactor toward a pattern

It is often stronger to present a direct design, then explain the follow-up that would justify extracting a pattern. This demonstrates that abstraction is a response to evidence.

Concrete example

Begin with one NotificationSender. When email and SMS have distinct provider contracts, introduce a DeliveryChannel interface and adapters at the integration edge.

Interviewer follow-ups

What requirement would trigger this extraction?
Can we keep the public contract stable while changing the internals?

Do not over-engineer: Do not call every composition relationship dependency injection; describe the actual collaboration.

Validate the design, not the diagram

Walk one representative flow

Implement the direct use case.
Introduce a follow-up that creates real variation or mismatch.
Extract the smallest stable boundary.
Compare the new indirection cost with the expected change frequency.

Tests that protect the reasoning

The direct implementation still passes before extraction.
Two real policy variants satisfy the same behavior contract.
Removing the variation would make the abstraction unnecessary.

Evolve it without losing the boundary

Follow-up change: Add a second pricing regime and explain why Strategy is now earned but Factory or Observer still is not.
Concurrency, when relevant: Patterns do not imply thread safety; name concurrency only when the underlying state and interleaving make it relevant.
System Design boundary: Repository, Adapter, or Command may expose an architectural boundary, but storage topology and distributed execution remain System Design concerns.

What depth looks like by level

Entry: Prefer direct composition and explain one pattern simply.
Mid: Tie abstraction to a concrete variation.
Senior: Compare refactoring, coupling, and failure-boundary costs.
Staff+: Explain when the pattern belongs to a platform or organizational boundary rather than the local model.

Reach this point to mark the lesson as read.

Interview decision

Name a pattern only after identifying the concrete change force or mismatch it solves and the cost it introduces.

Mental modelPatterns are vocabulary for earned boundaries, not ingredients in a correct answer.

Use it to

Strategy for genuinely variable dispatch or pricing policy.
Adapter for a provider contract mismatch.
State objects only when state-specific behavior outgrows guarded transitions.

Keep out of scope

Covering the Gang of Four catalog.
Predicting speculative extension points.

See the responsibility boundary

A notification sender begins as one direct channel; email and SMS provider mismatches later earn adapters, while variable selection policy may earn Strategy.

Interface sketchTypeScript

interface PricingPolicy {
  fee(ticket: ClosedTicket, at: Instant): Money;
}
// Keep one FeeCalculator until pricing truly varies.

Pattern follows pressure or problem

Concrete example

Use Strategy for pricing rules that vary by vehicle or day; keep a single FeeCalculator method when there is only one stable rule.

Interviewer follow-ups

What concrete variation makes this useful?
What stays simpler if we do not add it yet?

Do not over-engineer: Do not award yourself a Factory, Observer, and Repository for every interview prompt.

Choose a pattern from its boundary

Concrete example

A delivery workflow uses an Adapter for a carrier API and a Strategy for routing. It does not need Observer unless multiple independent reactions must occur after status changes.

Interviewer follow-ups

Which behavior varies independently?
Is this an external contract or a local policy?

Do not over-engineer: Do not force every object through a factory just because objects are constructed.

Refactor toward a pattern

It is often stronger to present a direct design, then explain the follow-up that would justify extracting a pattern. This demonstrates that abstraction is a response to evidence.

Concrete example

Begin with one NotificationSender. When email and SMS have distinct provider contracts, introduce a DeliveryChannel interface and adapters at the integration edge.

Interviewer follow-ups

What requirement would trigger this extraction?
Can we keep the public contract stable while changing the internals?

Do not over-engineer: Do not call every composition relationship dependency injection; describe the actual collaboration.

Validate the design, not the diagram

Walk one representative flow

Implement the direct use case.
Introduce a follow-up that creates real variation or mismatch.
Extract the smallest stable boundary.
Compare the new indirection cost with the expected change frequency.

Tests that protect the reasoning

The direct implementation still passes before extraction.
Two real policy variants satisfy the same behavior contract.
Removing the variation would make the abstraction unnecessary.

Evolve it without losing the boundary

Follow-up change: Add a second pricing regime and explain why Strategy is now earned but Factory or Observer still is not.
Concurrency, when relevant: Patterns do not imply thread safety; name concurrency only when the underlying state and interleaving make it relevant.
System Design boundary: Repository, Adapter, or Command may expose an architectural boundary, but storage topology and distributed execution remain System Design concerns.

What depth looks like by level

Entry: Prefer direct composition and explain one pattern simply.
Mid: Tie abstraction to a concrete variation.
Senior: Compare refactoring, coupling, and failure-boundary costs.
Staff+: Explain when the pattern belongs to a platform or organizational boundary rather than the local model.

Reach this point to mark the lesson as read.

What you will learn

Name a pattern only after identifying the concrete change force or mismatch it solves and the cost it introduces.

Use it to

Keep out of scope

See the responsibility boundary

Pattern follows pressure or problem

Choose a pattern from its boundary

Refactor toward a pattern

Validate the design, not the diagram

Walk one representative flow

Tests that protect the reasoning

Evolve it without losing the boundary

What depth looks like by level

Use the idea in a complete design.

Finish this lesson

Use design patterns only when pressure earns them

What you will learn

Name a pattern only after identifying the concrete change force or mismatch it solves and the cost it introduces.

Use it to

Keep out of scope

See the responsibility boundary

Pattern follows pressure or problem

Choose a pattern from its boundary

Refactor toward a pattern

Validate the design, not the diagram

Walk one representative flow

Tests that protect the reasoning

Evolve it without losing the boundary

What depth looks like by level

Use the idea in a complete design.

Finish this lesson

Name a pattern only after identifying the concrete change force or mismatch it solves and the cost it introduces.

Use it to

Keep out of scope

See the responsibility boundary

Pattern follows pressure or problem

Choose a pattern from its boundary

Refactor toward a pattern

Validate the design, not the diagram

Walk one representative flow

Tests that protect the reasoning

Evolve it without losing the boundary

What depth looks like by level

Use the idea in a complete design.

Continue the curriculum

Finish this lesson

Name a pattern only after identifying the concrete change force or mismatch it solves and the cost it introduces.

Use it to

Keep out of scope

See the responsibility boundary

Pattern follows pressure or problem

Choose a pattern from its boundary

Refactor toward a pattern

Validate the design, not the diagram

Walk one representative flow

Tests that protect the reasoning

Evolve it without losing the boundary

What depth looks like by level

Use the idea in a complete design.

Continue the curriculum

Finish this lesson