Pattern Selection Framework

The 23 patterns in the Gang of Four book are not the complete universe of software design solutions. They're not even the complete universe of patterns. Treating the GoF catalog as a menu from which you must order limits your design options unnecessarily.

The Real Design Space

For any given problem, your actual solution options include:

1. A catalog pattern applied as-is
2. A catalog pattern adapted/modified for your context
3. A combination of multiple patterns
4. A pattern from outside the GoF catalog
5. A domain-specific idiom that's pattern-like but not formal
6. A simple, pattern-free custom solution
7. No new design at all—the current approach is fine

Experienced engineers move fluidly across this spectrum. They don't force problems into pattern-shaped boxes; they select from the full range of design tools.

Patterns are templates, not blueprints. The canonical form documented in books rarely matches real-world implementations exactly. Skilled engineers adapt patterns to fit context while preserving the pattern's essential structure and intent.

What Can Be Modified

Pattern modifications fall into categories:

Structural Simplifications

• Eliminate optional participants when unnecessary
• Combine participants when they're always used together
• Use language features that simplify structure (lambdas for strategy, mixins for decorator)

Implementation Variations

• Different selection mechanisms (configuration, discovery, convention)
• Lazy vs. eager instantiation
• Thread-safe vs. single-threaded variants
• Memory-optimized vs. clarity-optimized

Scope Adjustments

• Apply at different granularity (class, module, service)
• Partial application to subset of behaviors

Complex problems often require multiple patterns working together. Pattern combination is an advanced skill that requires understanding how patterns interact.

Common Pattern Combinations

Example: Strategy + Factory Combination

Problem: Payment processing with many providers. Strategy fits, but selecting the right strategy requires complex logic (user preferences, regional availability, transaction type, fallback rules).

Strategy alone pushes selection complexity to clients.

Strategy + Factory encapsulates selection:

// Strategy (payment method)
interface PaymentProcessor {
  process(amount: number, details: PaymentDetails): Promise<Result>;
}

// ConcreteStrategies
class StripeProcessor implements PaymentProcessor { /* ... */ }
class PayPalProcessor implements PaymentProcessor { /* ... */ }
class ApplePayProcessor implements PaymentProcessor { /* ... */ }

// Factory (encapsulates selection logic)
class PaymentProcessorFactory {
  constructor(
    private featureFlags: FeatureFlags,
    private geoService: GeoService,
    private userPreferences: UserPreferencesService
  ) {}
  
  async createProcessor(
    user: User, 
    order: Order
  ): Promise<PaymentProcessor> {
    // Complex selection logic hidden here
    const region = await this.geoService.getRegion(user);
    const preferred = await this.userPreferences.getPaymentPreference(user);
    
    if (this.featureFlags.isEnabled('apple-pay', region) && preferred === 'apple') {
      return new ApplePayProcessor(this.getApplePayConfig(region));
    }
    if (order.amount > 10000) {
      return new StripeProcessor(this.getHighValueConfig());
    }
    // ... more rules
    return new PayPalProcessor(this.getDefaultConfig());
  }
}

// Client is simple
class CheckoutService {
  constructor(private factory: PaymentProcessorFactory) {}
  
  async checkout(user: User, order: Order) {
    const processor = await this.factory.createProcessor(user, order);
    return processor.process(order.total, order.paymentDetails);
  }
}

Each pattern does its job:

• Factory: Encapsulates complex creation/selection logic
• Strategy: Provides polymorphic payment processing
• Combined: Clean separation of what (Strategy) from which (Factory)

The Gang of Four book published 23 patterns in 1994. The pattern community has documented hundreds more covering domains the GoF book didn't address.

Important Pattern Catalogs

Selected Non-GoF Patterns You Should Know

Null Object Pattern

Problem: Code littered with null checks. Special case handling scattered everywhere.

Solution: Provide a do-nothing object that satisfies the interface. Replace null with this object.

// Instead of null checks everywhere
interface Logger {
  log(message: string): void;
}

class ConsoleLogger implements Logger {
  log(message: string) { console.log(message); }
}

class NullLogger implements Logger {
  log(message: string) { /* do nothing */ }
}

// Usage: no null checks needed
class Service {
  constructor(private logger: Logger = new NullLogger()) {}
  
  doWork() {
    this.logger.log('Starting'); // works with or without real logger
    // ...
  }
}

Repository Pattern

Problem: Domain logic coupled to data access details (SQL queries, ORM specifics).

Solution: Abstract data access behind a collection-like interface.

Circuit Breaker Pattern

Problem: Failing external dependency brings down entire system through cascading timeouts.

Solution: Wrap external calls; track failures; "open" circuit after threshold; fail fast while open; periodically probe to recover.

Each programming language and framework has idioms—conventional ways of solving problems that may not rise to the level of formal patterns but represent community wisdom.

When Idioms Replace Patterns

Modern languages often have features that make certain patterns unnecessary or transform them into simpler idioms:

Singleton → Module/Object Constant

JavaScript ES6+ modules are singletons by default:

// config.ts
export const config = {
  apiUrl: process.env.API_URL,
  timeout: 5000,
};

// Every import gets the same object instance
import { config } from './config';

No private constructor, no static getInstance. The module system provides singleton semantics.

Strategy → Higher-Order Functions

Functional languages make Strategy nearly invisible:

const sort = (arr: number[], compare: (a: number, b: number) => number) =>
  [...arr].sort(compare);

const ascending = (a: number, b: number) => a - b;
const descending = (a: number, b: number) => b - a;

sort([3, 1, 2], ascending);  // [1, 2, 3]
sort([3, 1, 2], descending); // [3, 2, 1]

Observer → Native Event Systems

Many frameworks provide observable/event primitives:

// Angular/RxJS
@Component({ /* ... */ })
class StockComponent {
  constructor(private stockService: StockService) {}
  
  ngOnInit() {
    this.stockService.priceChanges$.subscribe(
      price => this.updateDisplay(price)
    );
  }
}

Decorator → Language Decorators/Annotations

TypeScript/Python decorators provide pattern-like behavior:

// TypeScript class decorators
@Injectable()
@LogMethodCalls()
class UserService {
  @Memoize({ ttl: 60 })
  getUser(id: string): User {
    // expensive operation
  }
}

The most overlooked alternative to patterns is the humble simple solution. Patterns add abstraction and indirection. Sometimes the problem doesn't warrant that cost.

Signs That Simple Is Better

The Pattern Tax

Every pattern incurs costs:

• Cognitive cost — Readers must understand the pattern to understand the code
• Navigational cost — Behavior is distributed across multiple files/classes
• Modification cost — Adding new members means touching multiple places
• Testing cost — More classes means more test files
• Abstraction cost — Each layer hides behavior, making debugging harder

Patterns pay for these costs through benefits like extensibility, testability, and maintainability. When benefits don't exceed costs, the pattern is net negative.

The YAGNI Consideration

You Aren't Gonna Need It applies to patterns. If you're adding Strategy because you might need more strategies someday, you're speculating. Start simple; refactor to patterns when actual needs emerge. It's easier to extract a pattern from working code than to remove an unnecessary pattern.

Sometimes your problem genuinely doesn't fit any catalog pattern. This is especially true for domain-specific problems where business rules don't map to general object interaction patterns.

When Custom Design Is Appropriate

• Novel problem domain — Your problem space hasn't been pattern-mined yet
• Unusual constraint combinations — Standard patterns don't satisfy your specific constraints
• Performance/resource requirements — Catalog patterns are too general for your optimization needs
• Temporary solutions — You need something fast that will be replaced; patterns add unnecessary structure

Designing Custom Solutions

Use pattern principles even when not applying specific patterns:

1. Single Responsibility Each component does one thing well

2. Separation of Concerns Distinct concerns go in distinct components

3. Dependency Inversion Depend on abstractions, not concretions

4. Interface Segregation Clients shouldn't depend on methods they don't use

5. Composition Over Inheritance Prefer composing objects to inheriting behavior

Example: Custom Event Processing Design

Problem: Events arrive from multiple sources. Each event type needs different validation, enrichment, and routing. Events can fail at any stage and need different retry strategies. Volume is high; latency matters.

Why Patterns Don't Fit Perfectly:

• Chain of Responsibility: Good for routing, but doesn't handle branching or parallel processing
• Observer: Good for notification, but doesn't handle processing pipelines
• Strategy: Good for algorithms, but event processing isn't pure algorithm variation

Custom Design:

// Custom pipeline design borrowing from multiple patterns
interface EventHandler<T, R> {
  canHandle(event: T): boolean;
  handle(event: T): Promise<R>;
}

interface PipelineStage<T, R> {
  process(event: T): Promise<StageResult<R>>;
}

type StageResult<R> = 
  | { status: 'continue'; result: R }
  | { status: 'skip'; reason: string }
  | { status: 'retry'; delay: number }
  | { status: 'fail'; error: Error };

class EventPipeline<T> {
  private stages: PipelineStage<T, T>[] = [];
  
  addStage(stage: PipelineStage<T, T>): this {
    this.stages.push(stage);
    return this;
  }
  
  async process(event: T): Promise<PipelineResult<T>> {
    let current = event;
    for (const stage of this.stages) {
      const result = await stage.process(current);
      switch (result.status) {
        case 'continue':
          current = result.result;
          break;
        case 'skip':
          return { status: 'skipped', reason: result.reason };
        case 'retry':
          // Queue for retry with delay
          return { status: 'deferred', delay: result.delay };
        case 'fail':
          return { status: 'failed', error: result.error };
      }
    }
    return { status: 'completed', result: current };
  }
}

This borrows ideas from:

• Chain of Responsibility (stage pipeline)
• Strategy (pluggable handlers)
• Builder (fluent addStage)
• Railway-oriented programming (result types)

But it's not any single pattern. It's a custom design that fits the specific problem.

Choosing between catalog patterns, variants, combinations, and custom solutions requires systematic thinking. Here's a decision framework:

Evaluation Criteria for Each Alternative

Skilled engineers draw from a full palette of design options, not just the 23 GoF patterns. Knowing when and how to use alternatives makes you a more effective designer.

What's Next:

The final page in this module provides the Decision Checklist—a comprehensive set of questions to work through before finalizing any pattern selection. It consolidates everything you've learned into a practical evaluation tool.