Design Patterns Choosing the Right Pattern

Knowing twenty patterns is easy. Picking the correct one for a real problem takes a method. A reliable approach starts with the problem, moves to the category, and ends with a short comparison of candidates.

The Layman's View

A carpenter does not grab a hammer for every job. Screws need a screwdriver, and boards need a saw. Patterns work as tools in a toolbox. The skill lies in reading the job first and reaching for the matching tool.

A Four-Step Method

Step 1  Describe the problem in plain words
           │
           ▼
Step 2  Find the pain: creation? structure? behavior?
           │
           ▼
Step 3  Shortlist 2-3 patterns from that category
           │
           ▼
Step 4  Compare costs, then pick the simplest fit

Step 1: State the Problem

Write one sentence without pattern names. "Several payment providers need the same checkout steps" is a clear problem. "We need a Strategy" is a conclusion without a problem.

Step 2: Identify the Pain Area

Pain	Category
Hard to create objects cleanly	Creational
Classes fit together badly	Structural
Objects coordinate or react poorly	Behavioral
Whole application layout feels tangled	Architectural

Step 3: Use a Problem-to-Pattern Map

CREATION
  One shared instance only .............. Singleton
  Choose a class at runtime ............. Factory Method
  Families of matching objects .......... Abstract Factory
  Many optional settings ................ Builder
  Copy an existing object ............... Prototype
  Reuse costly objects .................. Object Pool

STRUCTURE
  Old class, new interface .............. Adapter
  Add features without subclassing ...... Decorator
  Simplify a messy subsystem ............ Facade
  Tree of parts and wholes .............. Composite
  Control access or delay loading ....... Proxy
  Two dimensions of variation ........... Bridge
  Millions of similar objects ........... Flyweight

BEHAVIOR
  Notify many listeners ................. Observer
  Swap algorithms ....................... Strategy
  Turn actions into objects ............. Command
  Walk through a collection ............. Iterator
  Fixed steps, variable details ......... Template Method
  Behavior depends on condition ......... State
  Pass a request along a line ........... Chain of Responsibility
  Peers talk through a hub .............. Mediator
  Undo and snapshots .................... Memento
  New operations on stable classes ...... Visitor
  Small rule language ................... Interpreter
  Avoid null checks ..................... Null Object

Step 4: Compare Similar Candidates

Strategy or State?

Strategy fits when the client chooses the algorithm. State fits when the object changes its own behavior over time.

Decorator or Proxy?

Decorator adds features. Proxy controls access.

Factory Method or Abstract Factory?

Factory Method suits one product. Abstract Factory suits a family of related products.

Adapter or Facade?

Adapter converts one interface. Facade simplifies many interfaces.

Worked Example

Problem: "An online shop applies festival, member, or coupon discounts.
          New discount types appear every season."

Pain area .......... behavior (the algorithm changes)
Shortlist .......... Strategy, Template Method, State
Compare ............ Client picks the discount → Strategy
                     Steps fixed, details vary → Template Method (less flexible)
                     Discount depends on order status → State (not the case)
Decision ........... Strategy

Warning Signs of a Wrong Choice

• The pattern needs five new classes for a two-line problem.
• Teammates cannot explain why the pattern exists.
• Future changes look harder than before.
• The code works fine in a simpler form.

Simplicity Check

Try the plain solution first. A small function or an extra parameter often solves the problem. Adopt a pattern when repeated pain appears, such as a third copy of the same if-else chain. Patterns repay their cost when change is likely.

Practice Scenarios

Try the method on three small problems. Write the problem sentence, name the pain area, and list two candidate patterns before reading the hints.

Scenario One

A report must export to PDF, spreadsheet, or plain text, and new formats arrive often. The pain involves swappable algorithms, which points to Strategy. Factory Method helps choose the exporter by name.

Scenario Two

A smart-home app must switch lights, fans, and music when a user says "movie night." The pain involves bundling many actions behind one request. Command or Facade fits, depending on whether undo matters.

Scenario Three

A game spawns thousands of identical trees and strains memory. The pain involves shared data, which points to Flyweight.

Questions to Ask Teammates

• What change do we expect in the next six months?
• Which part of this code do people fear to touch?
• Would a plain function solve this with less code?

Key Takeaways

• Start from the problem, never from the pattern name.
• Categories narrow the search to a short list.
• Compare similar patterns by intent, not by diagram shape.
• Prefer the simplest solution that handles likely change.