Choosing the Right Pattern

Analogy categoryAnalogies

Choosing the right design pattern starts with correctly diagnosing the problem, not with picking a favorite pattern and looking for a place to use it. The most reliable approach is to name the specific symptom in the existing code first — repeated conditional branches on type, an object with too many constructor parameters, tightly coupled classes that are hard to test in isolation — and then match that symptom to the smallest pattern that resolves it. Jumping straight to an architecture diagram full of patterns before writing the simplest working version almost always produces an over-engineered result that's harder to change than plain code would have been.

🏏

Cricket analogy: A captain diagnosing that the opposition is weak against short-pitched bowling before setting the field, rather than copying a generic aggressive field from another match, mirrors matching a pattern to the actual diagnosed symptom in code.

A Practical Decision Framework

A workable heuristic: if you're duplicating creation logic across the codebase, look at Factory Method or Abstract Factory; if a class is accumulating conditional branches based on an object's type or state, consider Strategy or State; if unrelated objects need to react to one object's changes, consider Observer; if you need to add optional behavior without an explosion of subclasses, consider Decorator; if two incompatible interfaces need to cooperate, consider Adapter. Crucially, this matching should happen after you've felt the pain of the problem in real code — writing the simplest solution first and refactoring toward a pattern once a second or third variation appears is safer than guessing upfront which pattern a not-yet-written feature will need.

🏏

Cricket analogy: A team only invests in specialist death-overs bowling coaching once they've actually lost multiple matches in the final overs, not before facing that specific recurring problem, mirroring refactoring toward a pattern only after the pain is felt.

python

# Refactor toward a pattern once real duplication appears, not before.

# Version 1: two payment types, simple if/else is fine
def process_payment(kind, amount):
    if kind == "credit_card":
        return f"Charged ${amount} to card"
    elif kind == "paypal":
        return f"Sent ${amount} via PayPal"

# Version 2: a third and fourth type appear, conditionals keep growing ->
# NOW refactor toward Strategy, because the pain (duplication, growing
# branching) is real, not hypothetical.
class PaymentStrategy:
    def pay(self, amount): raise NotImplementedError

class CreditCardStrategy(PaymentStrategy):
    def pay(self, amount): return f"Charged ${amount} to card"

class PayPalStrategy(PaymentStrategy):
    def pay(self, amount): return f"Sent ${amount} via PayPal"

class CryptoStrategy(PaymentStrategy):
    def pay(self, amount): return f"Transferred ${amount} in crypto"

class GiftCardStrategy(PaymentStrategy):
    def pay(self, amount): return f"Redeemed ${amount} from gift card"

Common Mistakes When Selecting a Pattern

The most common mistake is 'pattern hammer' syndrome — having just learned Observer, a developer starts seeing pub/sub opportunities everywhere, including places where a simple direct method call would be clearer. The second common mistake is combining too many patterns in one place, producing a maze of Factories creating Strategies wrapped in Decorators that no one on the team can trace during an incident at 2 a.m. The fix for both is the same discipline: prefer the simplest structure that solves the diagnosed problem, add a pattern only when a specific, named pain point justifies the added indirection, and be willing to remove a pattern later if the assumptions that justified it change.

🏏

Cricket analogy: A bowler who just learned a devastating slower ball starts bowling it every single delivery regardless of the batter or situation, the way a developer who just learned Observer starts applying pub/sub everywhere regardless of fit.

A good litmus test before adding a pattern: can you point to a specific line of code, or a specific bug report, that the pattern would have prevented or simplified? If not, you may be solving an imagined problem instead of a real one.

Combining multiple patterns in a single feature — a Factory that creates Strategies wrapped in Decorators managed by a Mediator — can quickly become unreadable. Each additional pattern layer should pay for itself in reduced complexity elsewhere; if it doesn't, simplify.

Diagnose the specific symptom in the code first; don't start from a favorite pattern.
Repeated type-based conditionals often point to Strategy or Factory Method.
Cross-object reactions to one object's changes often point to Observer.
Optional behavior without subclass explosion often points to Decorator.
Incompatible interfaces needing to cooperate often point to Adapter.
Refactor toward a pattern once real duplication or pain appears — don't guess upfront.
Avoid 'pattern hammer' syndrome and stacking too many patterns in one place.