Pattern Selection Framework

You've identified your problem. You've categorized it into a problem family. You have 3-5 candidate patterns. Now comes the critical question: Which pattern actually fits?

Pattern evaluation is where good engineers distinguish themselves from pattern enthusiasts. A pattern enthusiast picks the most elegant pattern. A good engineer picks the pattern that solves the problem with acceptable tradeoffs. Sometimes that's the elegant solution; often it's the boring one.

The Uncomfortable Truth About Pattern Fit

No pattern is a perfect fit. Every pattern comes with costs—additional abstraction, indirection, complexity, or constraints on future evolution. Pattern evaluation isn't about finding a perfect match; it's about finding the pattern where the benefits significantly outweigh the costs for your specific context.

Each design pattern is defined by more than its structure. A pattern's full definition includes:

• Intent — What problem the pattern solves
• Applicability — In what contexts the pattern applies
• Participants — The collaborating elements and their roles
• Consequences — What tradeoffs the pattern introduces

Fit evaluation examines each dimension:

Every pattern has a stated intent—a concise description of what problem it addresses. Intent match is your first evaluation gate.

Canonical Pattern Intents (from the Gang of Four and common sources):

How to Evaluate Intent Match

Compare your problem statement directly against the pattern intent:

Example Problem Statement:

"Our notification system has four delivery channels (email, SMS, push, Slack). Each channel has different APIs and logic. We need to add new channels without modifying existing notification logic. The core notification process (preferences check, logging, rate limiting) must remain consistent."

Comparing Against Strategy Intent:

"Define a family of algorithms, encapsulate each, make them interchangeable."

• ✅ Family of algorithms → Four delivery channel implementations
• ✅ Encapsulate each → Each channel is self-contained
• ✅ Make interchangeable → Core notification code works with any channel
• ✅ Vary independently → Add channels without touching core logic

Intent Match Score: Strong

Comparing Against Decorator Intent:

"Attach additional responsibilities to an object dynamically."

• ❌ Additional responsibilities → We're not augmenting; we're substituting
• ❌ Dynamically → Channel is selected once, not layered
• ❌ Alternative to subclassing → Not the problem being solved

Intent Match Score: Weak

Strategy passes the intent match filter; Decorator doesn't. This doesn't mean Decorator is bad—it means Decorator isn't designed for this problem.

Pattern documentation typically includes explicit applicability conditions—contexts where the pattern is appropriate. Treat these as a checklist.

Example: Strategy Pattern Applicability (from GoF)

Use Strategy when:

1. Many related classes differ only in their behavior
2. You need different variants of an algorithm
3. An algorithm uses data that clients shouldn't know about
4. A class defines many behaviors as conditional statements

Verification for Notification System:

When Conditions Partially Match

Rarely will all conditions apply perfectly. Evaluate whether:

• Core conditions match — Some conditions are definitional; missing these is disqualifying
• Optional conditions apply — Some conditions describe bonus benefits, not requirements
• Partial matches indicate variants — A partial match might mean a simpler or different pattern fits better

Red Flags in Applicability Verification:

Every pattern defines participants—the roles that collaborate to form the pattern. To apply a pattern, you must map your domain elements to these roles clearly and naturally.

Strategy Pattern Participants:

• Strategy: Interface declaring algorithm operations
• ConcreteStrategy: Implements the algorithm
• Context: Configures with a ConcreteStrategy, maintains reference, may delegate entirely

Mapping to Notification System:

Quality Checks for Participant Mapping

1. Natural Fit: Do domain elements map to pattern roles without conceptual gymnastics? A forced mapping indicates misfit.

2. Complete Coverage: Can you identify all pattern participants in your domain? Missing participants might mean you need pattern pieces you don't have.

3. Responsibility Alignment: Do your domain elements' responsibilities match what the pattern expects of each participant? Responsibility mismatch causes implementation friction.

4. Cardinality Match: Does your domain have the right number of elements? Strategy expects one Context and multiple ConcreteStrategies—do you have that structure?

Example of Poor Participant Mapping

Suppose we tried to map Decorator to our notification system:

• Component: NotificationChannel?
• ConcreteComponent: Base notification sender?
• Decorator: ???
• ConcreteDecorator: Each channel as a decorator?

This mapping breaks down immediately. Decorator expects nested wrapping (each decorator wraps another component). Our channels don't wrap each other—they're alternatives, not layers. Participant mapping fails, signaling poor fit.

Every pattern comes with consequences—explicit tradeoffs that you inherit by adopting the pattern. Consequence analysis is the most important and most overlooked step in pattern evaluation.

Strategy Pattern Consequences (from GoF):

Benefits:

1. Families of related algorithms
2. Alternative to subclassing
3. Eliminates conditional statements
4. Choice of implementations

Costs:

1. Clients must be aware of different strategies
2. Communication overhead between Strategy and Context
3. Increased number of objects

Evaluating Consequence Acceptability

Context-Dependent Consequence Evaluation

Consequences that are acceptable in one context may be dealbreakers in another:

Example: Increased Object Count Consequence

• General Web Application: Acceptable. Objects are cheap; clarity is worth memory.
• Embedded System with 256KB RAM: Potentially unacceptable. Each strategy object consumes precious memory.
• Hot Path with 10M calls/second: Requires analysis. Are strategies allocated per-call or pooled/singleton?

Example: Client Awareness Consequence

• Internal API with educated developers: Acceptable. Team understands pattern.
• Public SDK for external developers: Requires careful design. External developers shouldn't need to understand your internal patterns.

Unacceptable Consequences = Pattern Rejection

If any consequence is genuinely unacceptable given your constraints, the pattern doesn't fit—regardless of how well intent, applicability, and participants matched. You need a different solution.

When multiple patterns pass individual evaluation, you need systematic comparison. This prevents defaulting to the pattern you know best rather than the pattern that fits best.

Comparison Framework: Weighted Criteria Matrix

Create a matrix with evaluation dimensions, weight each dimension by importance to your context, and score each candidate pattern.

Adjusting Weights

Weight selection matters. Common weight considerations:

• High-risk project: Weight consequence acceptability higher
• Legacy integration: Weight implementation complexity higher
• Rapid prototype: Weight team familiarity and implementation speed higher
• Long-term maintainability: Weight intent match and participant mapping higher

Tie-Breaking Principles

When scores are close:

1. Prefer simpler patterns — Given equivalent scores, simpler patterns have lower hidden costs
2. Prefer patterns the team knows — Execution quality depends on implementation skill
3. Prefer patterns with less infrastructure — Each abstraction layer has maintenance cost
4. Prefer patterns enabling future change — Today's close choice may be tomorrow's clear winner

When No Pattern Wins Clearly

If weighted scores are truly equivalent, consider:

• Can you combine patterns? (Some patterns compose naturally)
• Is the problem scope too broad? (Multiple sub-problems might each need different patterns)
• Is a custom solution more appropriate? (Not every problem maps to catalog patterns)

Sometimes, honest evaluation reveals that no pattern adequately addresses your problem. This is a valid—and often correct—conclusion. Forcing a pattern when none fits creates more problems than it solves.

Signs That No Pattern Fits

Alternatives When Patterns Don't Fit

1. Simple Procedural Solution

   • Not every problem needs a pattern. If a straightforward function with conditionals is clear and maintainable, use it.
   • Come back to patterns when complexity genuinely warrants the abstraction.

2. Custom Hybrid Design

   • Borrow ideas from patterns without full implementation.
   • Example: Use strategy-like interface extraction without formal Context/Strategy structure.

3. Decompose the Problem

   • Your single problem might be multiple sub-problems.
   • Apply different patterns to different parts.

4. Architectural Patterns

   • Problem might be too large for object patterns.
   • Consider MVC, Microservices, Event Sourcing, CQRS.

5. Accept Technical Debt

   • Implement a non-ideal solution now.
   • Revisit when problem clarifies or constraints change.

Let's walk through a complete pattern evaluation for a realistic problem.

Problem Statement

Our e-commerce order processing has grown complex. An order can be in states: Draft, Submitted, PaymentPending, PaymentFailed, PaymentComplete, Shipped, Delivered, Cancelled. Different operations are valid in different states. Currently, every operation method has a switch statement checking current state. Adding new states or changing state-specific logic requires modifying multiple switch statements across many methods.

Problem Analysis Recap (from previous page):

• Root Cause: State-dependent behavior scattered across operations
• Forces: Need to add states safely; need clear per-state behavior
• Problem Category: State Management
• Pattern Candidates: State, Strategy

Evaluating State Pattern

Evaluating Strategy Pattern

Comparison Result:

• State Pattern: 9/10 average
• Strategy Pattern: 4.25/10 average

Conclusion: State pattern fits strongly. Strategy pattern doesn't fit—not because it's bad, but because our problem is state-transition behavior, not algorithm substitution.

Implementation Decision:

Proceed with State pattern. Create:

• OrderState interface with operations: submit(), processPayment(), ship(), deliver(), cancel()
• 8 concrete state classes, each implementing allowed operations and throwing/no-op for disallowed ones
• Order (Context) holds current state, delegates operations to state, updates state based on transition methods

This analysis, document, and decision took perhaps an hour. It will save weeks of debugging scattered switch statements as order complexity grows.

Pattern evaluation transforms pattern selection from intuition to engineering. Use structured evaluation to ensure pattern fit.

What's Next:

With your pattern candidates evaluated, the next page covers Considering Alternatives—exploring solutions beyond the standard pattern catalog, including pattern variants, combinations, and non-pattern solutions that might better serve your needs.