How to Choose the Right Design Pattern in C#

You have read 23 patterns. You have a problem in front of you. Which one do you reach for? This article is the bridge between the patterns and the daily work — a decision tree that maps real-world symptoms to the right pattern, plus the comparison matrices that resolve the four or five "wait, which one was that?" pairings that show up in every code review.

Read this once when you finish the series. Bookmark it for the next time you stare at a refactor and ask "which pattern should this be?".

Where do I start with three questions, then a pattern?

Every design-pattern decision in modern C# fits into a tree three levels deep. Ask in order:

flowchart TB
    Q1{What is the problem about?}
    Q1 -->|How an object is created| Creational
    Q1 -->|How objects are wired together| Structural
    Q1 -->|How objects act and talk| Behavioral

    Creational --> Q2A{What kind of creation?}
    Q2A -->|Share one process-wide instance| Singleton[Singleton]
    Q2A -->|Pick which concrete class| FactMth[Factory Method]
    Q2A -->|Pick a family of related classes| AbsFac[Abstract Factory]
    Q2A -->|Many optional fields, validation| Bld[Builder]
    Q2A -->|Clone a configured template| Proto[Prototype]

    Structural --> Q2B{What kind of wiring?}
    Q2B -->|Mismatched interfaces| Ada[Adapter]
    Q2B -->|Two axes that vary together| Bri[Bridge]
    Q2B -->|Tree of leaves and groups| Comp[Composite]
    Q2B -->|Add cross-cutting behaviour| Dec[Decorator]
    Q2B -->|Hide a complex subsystem| Fac[Facade]
    Q2B -->|Share immutable instances| Fly[Flyweight]
    Q2B -->|Control access lazily / remotely| Pxy[Proxy]

    Behavioral --> Q2C{What kind of communication?}
    Q2C -->|Pipeline that may stop| CoR[Chain of Responsibility]
    Q2C -->|Wrap an action as data| Cmd[Command]
    Q2C -->|Evaluate a small DSL| Int[Interpreter]
    Q2C -->|Iterate without exposing structure| Iter[Iterator]
    Q2C -->|Many peers via a hub| Med[Mediator]
    Q2C -->|Snapshot for undo| Mem[Memento]
    Q2C -->|Notify subscribers| Obs[Observer]
    Q2C -->|Behaviour by lifecycle| Sta[State]
    Q2C -->|Swap one algorithm| Str[Strategy]
    Q2C -->|Skeleton with hooks| Tmp[Template Method]
    Q2C -->|New ops on closed nodes| Vis[Visitor]

Every leaf is a chapter you have already read. The next sections narrow the choice when two patterns look similar.

How does the decision tree look by symptom?

Below is the same tree expressed as "you have X symptom → read Y chapter". Skim it before you write any new code; the five minutes you spend here save the half-day refactor later.

Object creation symptoms

Composition symptoms

Behaviour symptoms

Which confusion matrices come up most in interviews?

These are the half-dozen "which one is this?" pairs that come up over and over.

Strategy vs State vs Command

The shape is identical: an interface implemented by several classes, picked at runtime. The intent is what differs.

→ See Strategy, State, Command.

Decorator vs Adapter vs Proxy

All three wrap one object behind a class.

→ See Decorator, Adapter, Proxy.

Factory Method vs Abstract Factory vs Builder

Three creational patterns that all involve "make stuff".

→ See Factory Method, Abstract Factory, Builder.

Mediator vs Observer

Both push notifications.

→ See Mediator, Observer.

Composite vs Decorator vs Iterator vs Visitor

These four come up around tree-shaped data.

→ See Composite, Decorator, Iterator, Visitor.

What do the modern .NET shapes look like at a glance?

The whole series is built around a single observation: every GoF pattern's textbook implementation has shrunk. The implementation maps to modern features:

If your code looks nothing like the row to the right, you are probably writing the 1994 implementation when the 2026 one exists. The intent survives; the implementation does not.

When should you NOT use any pattern?

The most over-applied advice in this series is "use a pattern". The most under-applied advice is "do not". Three signs that no pattern is the right answer:

• You have one variant. A Strategy interface with one implementation is overhead. Wait for the second.
• The framework already does it. ASP.NET Core's middleware is Chain of Responsibility; you do not need a hand-rolled one to validate a request.
• The cost outweighs the benefit. Three extra files for an abstraction nobody uses is a tax with no revenue. Patterns have to earn their existence.

The rule of three (referenced in the Introduction): wait until you have three concrete cases of the same problem before reaching for the pattern. Two is a coincidence; three is a pattern.

How do you read PR reviews after this series?

Once you know all 23 patterns, code reviews become a vocabulary exercise rather than a guessing game. Common review phrases that should now make immediate sense:

• "This is a Strategy that should be a State." — the chosen algorithm depends on the object's lifecycle, not the caller.
• "This is a Decorator that wants to be a Proxy." — the wrapper is controlling access, not adding behaviour.
• "This is a Facade with too many methods." — the application service has become a god class.
• "This Builder should be a record." — the construction has no staged validation, just optional fields.
• "This Visitor should be a switch expression." — the node hierarchy is closed and you control all cases.

When you can both give and receive these reviews fluently, the patterns have done their job: they are vocabulary for a conversation that used to be a 30-minute meeting.

Where should you read next in this series?

• Previous: Visitor — the last GoF pattern.
• Next: Conclusion — the wrap-up and what to read after the series.
• Series map: Introduction.
• Group outlines (internal): scan a single group when you need a refresher on its patterns and cross-references.

A final structural note. Every pattern in this series has the same seven sections: symptom, textbook shape, modern .NET shape, when to skip, comparison, real example, where next. That uniformity is deliberate — once you internalise the structure, re-reading any chapter takes five minutes. Treat the series as a reference, not a one-time read. The patterns matter most when you can find the right one in 30 seconds, not when you remember them all by heart.

For a quick code-level reminder, the most-frequent transformation this series taught is "lift inline behaviour into a swappable abstraction":

// Before — inline switch hard-codes the choice
public decimal Discount(string tier) => tier switch
{
    "silver" => 0.05m, "gold" => 0.10m, _ => 0m,
};

// After — Strategy via Func<>, plus DI registration
public sealed class CartCalculator
{
    private readonly Func<string, decimal> _discount;
    public CartCalculator(Func<string, decimal> discount) => _discount = discount;
    public decimal GrandTotal(string tier, decimal subtotal) => subtotal * (1m - _discount(tier));
}

That single transformation is the seed of half the patterns in this series. Recognise the seed and the rest follow.