Design Pattern Suggestor

A pattern is a named solution to a recurring structural problem. The value is the vocabulary, not the code. The risk is applying a pattern because it's familiar, not because the problem it solves is present.

Problem → pattern (NOT pattern → problem)

Start from the symptom. The pattern is the answer; the problem is the question.

The "or maybe just…" column matters

Most pattern misuse is applying GoF ceremony where the language already gives you the mechanism for free:

• Strategy in Python: Functions are first-class. strategies = {"a": fn_a, "b": fn_b} is the pattern.
• Singleton in Python/JS: A module IS a singleton. import config — done.
• Observer in anything with events: addEventListener, signals, Rx — the pattern is built into the runtime.
• Iterator: Every modern language has yield / generators. You don't write hasNext()/next().

If the "or maybe just" fits, use it. The pattern is the fallback for languages that lack the mechanism.

Anti-pattern detection

Sometimes the finding is "you're using a pattern wrong":

Worked example

Symptom: "Every time we add a payment method we have to edit process_payment() and validate_payment() and refund_payment() — three switches on method_type."

Match: Same switch, 3 places, on a type code → Strategy.

Check the "or maybe just": What language? Java. No first-class functions pre-lambdas (or the team doesn't use them). Strategy is the idiomatic fit.

Recommendation:

Three switches on method_type, growing with every new payment method → Strategy pattern.

interface PaymentMethod {
    void process(Payment p);
    ValidationResult validate(Payment p);
    void refund(Payment p);
}
class CreditCard implements PaymentMethod { ... }
class PayPal implements PaymentMethod { ... }

New payment method → one new class, zero edits to existing switches.

Counter-check: Do process/validate/refund always change together when a method is added? If validate is actually the same for 4 of 5 methods, Strategy will force you to duplicate it. Consider: Strategy for process/refund, a single validate with a small type check.

Do not

• Do not suggest a pattern without stating the problem it solves here. "Use Factory" is cargo cult. "Use Factory because which concrete class depends on a config value you don't know at compile time" is a reason.
• Do not apply Java-idiom patterns to languages that don't need them. Strategy in a language with first-class functions is just "pass a function."
• Do not add a pattern for a problem you might have. One concrete class? No Strategy. One way to build it? No Builder. YAGNI.
• Do not suggest Visitor unless the type hierarchy is closed and the operations are open. If you're adding types more often than operations, Visitor fights you.

Output format

## Symptom
<the structural problem — what hurts>

## Pattern fit
<pattern> — <why it matches this specific symptom>

## Or maybe just…
<simpler alternative if one exists — and when to prefer it>

## Sketch
<minimal code showing the pattern applied to THIS case, not a textbook example>

## When NOT to
<conditions under which this recommendation would be wrong>