Design Patterns

Reference: Design Patterns (GoF), Head First Design Patterns (Freeman & Robson), Refactoring to Patterns (Kerievsky)

When to Apply

• Selecting a pattern for a recurring design problem
• Refactoring code that exhibits a known code smell toward a pattern
• Reviewing whether an applied pattern is justified or over-engineered
• Deciding if a language feature (lambdas, protocols, generics) eliminates the need for a pattern
• Communicating design intent using shared pattern vocabulary

The Two GoF Maxims

Every pattern decision MUST be guided by these two principles:

1. Program to an interface, not an implementation — depend on abstractions; swap implementations without changing clients
2. Favor object composition over class inheritance — assemble behavior from collaborating objects rather than building class trees

Creational Patterns

Select based on what varies in object creation:

• MUST NOT use Singleton in new code — use dependency injection to manage single-instance lifecycle externally
• SHOULD prefer Builder over telescoping constructors when an object has 4+ configuration options
• SHOULD use Factory Method or Abstract Factory when the concrete type is a decision that should be deferred

Structural Patterns

Select based on how objects and classes are composed:

• SHOULD use Adapter as the primary pattern for integrating external systems
• SHOULD prefer Decorator over inheritance for optional, combinable behavior
• MUST separate intrinsic (shared) from extrinsic (contextual) state when applying Flyweight

Behavioral Patterns

Select based on how objects communicate and assign responsibility:

• SHOULD prefer Strategy over Template Method — composition over inheritance
• SHOULD use language-native constructs (iterators, lambdas, reactive streams) before implementing Iterator, Strategy, or Observer manually
• MUST evaluate whether the pattern adds value beyond what the language provides natively

Modern Patterns Beyond GoF

When NOT to Use Patterns

Pattern-itis — applying patterns speculatively — is worse than the problems patterns solve.

• MUST NOT apply a pattern when only one implementation exists and no variation is foreseeable
• MUST NOT use a pattern the team does not understand — it becomes accidental complexity
• SHOULD NOT apply patterns preemptively — refactor toward patterns when complexity emerges (Kerievsky)
• SHOULD start with the simplest thing that works; introduce a pattern when the code smell appears

Norvig's observation: 16 of 23 GoF patterns are simplified or eliminated by dynamic language features. Before applying a pattern, ask: "Does my language already solve this?"

Decision Flow

1. Identify the specific code smell or design problem
2. Check if a language feature solves it natively (generics, lambdas, protocols, pattern matching)
3. If not, select the pattern whose intent matches the problem
4. Apply the simplest form of the pattern — avoid gold-plating
5. Verify the pattern improves readability and maintainability for the team

Checklist

Before applying or recommending a pattern, verify:

• A specific, recurring problem has been identified (not speculative future need)
• Language-native features have been considered first
• The selected pattern's intent matches the actual problem
• The pattern improves — not hinders — code readability for the team
• Singleton is NOT used (DI container manages lifecycle instead)
• Composition-based patterns are preferred over inheritance-based ones
• The pattern is applied in its simplest form without unnecessary abstraction layers
• The code compiles and passes tests after applying the pattern

Key References