Confusable Patterns, Disambiguated

Once you have met all 23 patterns, the hard part is no longer what each one does — it is telling apart the ones that look almost identical. Strategy and State share the same UML. Adapter, Decorator, Proxy, Facade and Bridge are all "an object that wraps another object." This is the page you reach for when two patterns blur together: each cluster below shows why they look the same, a side-by-side table, the smallest possible C# that makes the difference visible, and a litmus-test question you can ask yourself to decide in seconds.

The litmus tests below are heuristics — fast clues that are usually right. The reliable differentiator is always the pattern's INTENT: what problem it exists to solve and what kind of change it isolates. When a clue and the intent disagree, trust the intent. Read each "clue in code" row as a tendency with counterexamples, not a law.

The pattern disambiguator

Answer one question at a time. Each choice narrows the field and logs the reasoning, so by the end you not only get a pattern name — you get the chain of "because…" that led there. That reasoning is the transferable skill; the answer is just the by-product.

1 · Strategy vs State

This is the classic trap, and for a good reason: their UML is identical. Both have a context object that holds a reference to an interface, and several concrete classes implementing that interface. If you photographed the two class diagrams and swapped the labels, nobody could tell.

// Client decides which algorithm; strategies never swap themselves.
var ctx = new Sorter();
ctx.SetStrategy(new QuickSort());   // outside code picks
ctx.Sort(data);
ctx.SetStrategy(new MergeSort());   // outside code picks again
ctx.Sort(data);

class QuickSort : ISortStrategy {
    public void Sort(int[] a) { /* ... */ }   // knows nothing of MergeSort
}

// A state transitions the context to the NEXT state from inside Handle.
class RedLight : ITrafficState {
    public void Next(TrafficLight ctx) {
        Console.WriteLine("Red → Green");
        ctx.State = new GreenLight();   // the state drives the change
    }
}
// Client just pushes time forward; it never names GreenLight.
light.Next();  // Red decides Green is next
light.Next();  // Green decides Yellow is next

Full treatment with problem-first walkthroughs: Strategy and State in Chapter 5.

2 · The wrapper family: Adapter · Decorator · Proxy · Facade · Bridge

All five are "an object that stands in front of another object and forwards calls to it." That single sentence is why students mix them up. The way to separate them is one question asked in a specific order: what happens to the interface?

The three "same interface" wrappers are the sharpest trap. Here they are as tiny contrasts — notice the method signature is the same in all three; only the body reveals which pattern it is.

interface IPrinter { void Print(string text); }

class LegacyWriter {                       // incompatible: wrong method name/shape
    public void WriteLine(string s) => Console.WriteLine(s);
}

class PrinterAdapter : IPrinter {          // NEW interface over OLD object
    private readonly LegacyWriter _legacy = new();
    public void Print(string text) => _legacy.WriteLine(text);  // translate call
}

interface ICoffee { decimal Cost(); }

class Espresso : ICoffee { public decimal Cost() => 2.0m; }

class MilkDecorator : ICoffee {            // SAME interface as what it wraps
    private readonly ICoffee _inner;
    public MilkDecorator(ICoffee inner) => _inner = inner;
    public decimal Cost() => _inner.Cost() + 0.5m;   // delegate + add
}
// Stackable — the tell-tale sign:
ICoffee c = new MilkDecorator(new MilkDecorator(new Espresso())); // 3.0m

interface IImage { void Display(); }

class RealImage : IImage {                 // expensive: loads from disk in ctor
    public RealImage(string f) { Console.WriteLine($"loading {f}"); }
    public void Display() => Console.WriteLine("drawing");
}

class ImageProxy : IImage {                // SAME interface, guards creation
    private readonly string _file; private RealImage? _real;
    public ImageProxy(string f) => _file = f;
    public void Display() {
        _real ??= new RealImage(_file);    // lazy: only load on first use
        _real.Display();
    }
}

// Subsystem: three fiddly classes with their own APIs.
class Amplifier { public void On() {} public void SetVolume(int v) {} }
class Projector { public void On() {} public void WideScreen() {} }
class Lights    { public void Dim(int pct) {} }

class HomeTheaterFacade {                   // ONE new door over MANY objects
    private readonly Amplifier _a = new(); private readonly Projector _p = new();
    private readonly Lights _l = new();
    public void WatchMovie() {              // the simple new interface
        _l.Dim(10); _p.On(); _p.WideScreen(); _a.On(); _a.SetVolume(8);
    }
}

interface IRenderer { void DrawCircle(float r); }     // implementation side
class VectorRenderer : IRenderer { public void DrawCircle(float r){} }
class RasterRenderer : IRenderer { public void DrawCircle(float r){} }

abstract class Shape {                                  // abstraction side
    protected readonly IRenderer R;                     // the BRIDGE field
    protected Shape(IRenderer r) => R = r;
    public abstract void Draw();
}
class Circle : Shape {
    private readonly float _r;
    public Circle(IRenderer r, float radius) : base(r) => _r = radius;
    public override void Draw() => R.DrawCircle(_r);
}
// Any Shape × any Renderer, no Circle-Vector / Circle-Raster subclass blowup.

Deep dives: Adapter · Decorator · Proxy · Facade · Bridge.

3 · Simple Factory · Factory Method · Abstract Factory · Builder

These all "make objects for you so the client doesn't say new ConcreteThing()." They differ in the level of the mechanism — is the creation logic a method, a class hierarchy, or a whole object? — and in what they create: one product, a family of related products, or one product assembled in steps.

static class ShapeFactory {
    public static IShape Create(string kind) => kind switch {
        "circle" => new Circle(),
        "square" => new Square(),
        _ => throw new ArgumentException(kind)
    };
}

abstract class Dialog {
    public void Render() { var b = CreateButton(); b.Paint(); }  // fixed flow
    protected abstract IButton CreateButton();                    // the hook
}
class WindowsDialog : Dialog {
    protected override IButton CreateButton() => new WindowsButton();
}

interface IGuiFactory {                    // a family of create-methods
    IButton CreateButton();
    ICheckbox CreateCheckbox();
}
class MacFactory : IGuiFactory {
    public IButton CreateButton() => new MacButton();
    public ICheckbox CreateCheckbox() => new MacCheckbox();   // always Mac-consistent
}

var burger = new BurgerBuilder()
    .AddPatty()
    .AddCheese()
    .NoOnions()
    .Build();          // one product, assembled step by step

See Factory Method, Abstract Factory and Builder in Chapter 3.

4 · Observer · Mediator · Pub/Sub

All three are about "when something happens, other things react." The real distinctions are who owns the subscription list, whether the publisher knows its subscribers, and whether a broker decouples the two ends in space and time. Whether delivery is synchronous or asynchronous, in-process or distributed, is a separate design choice — not part of the definition.

class Stock {                          // the subject
    private readonly List<IObserver> _obs = new();
    public void Subscribe(IObserver o) => _obs.Add(o);
    public void SetPrice(decimal p) {
        foreach (var o in _obs) o.Update(p);  // subject drives, directly
    }
}

bus.Subscribe("prices", msg => Console.WriteLine(msg));  // subscriber side
// ...elsewhere, a totally separate module:
bus.Publish("prices", "AAPL 190");                      // publisher side

// The publisher holds NO reference to any subscriber.
// The broker (bus) matches topic → handlers, often async.

See Observer and Mediator (Chapter 5), and Publish/Subscribe (Chapter 8).

5 · Command vs Strategy

Both turn "a thing you can do" into an object. The difference: a Strategy is a how (an interchangeable algorithm you plug in), while a Command is a what (a request captured as an object — with a receiver it acts on, and usually the ability to be queued, logged, or undone).

interface IShipping { decimal Cost(Order o); }
class Express : IShipping { public decimal Cost(Order o) => 15m; }

// Context just needs SOME way to compute; it's an algorithm slot.
decimal total = shipping.Cost(order);

interface ICommand { void Execute(); void Undo(); }

class TurnOn : ICommand {
    private readonly Light _light;          // the RECEIVER it acts on
    public TurnOn(Light l) => _light = l;
    public void Execute() => _light.On();
    public void Undo()    => _light.Off();  // reversible
}
// Queue them, log them, undo them:
history.Push(cmd); cmd.Execute();  /* later */ history.Pop().Undo();

Command · Strategy.

6 · Template Method vs Strategy

Both let a fixed process have varying parts. The mechanism is the whole difference: Template Method uses inheritance (subclasses override protected steps of a fixed algorithm baked into a base class), while Strategy uses composition (the context holds a separate object it delegates the varying part to).

Template Method · Strategy.

7 · Composite vs Decorator

Both are built by recursive composition — an object that implements an interface and also holds reference(s) to objects of that same interface. That shared skeleton is why they're confused. The difference is how many children and why: Composite is a tree of many to represent a part-whole hierarchy; Decorator is a chain of one to layer on behaviour.

Composite · Decorator.

8 · Iterator vs Visitor

These pair up so often that people fuse them, but they answer opposite questions. Iterator owns traversal — how to walk a collection element by element without exposing its internals. Visitor owns the operation — a new algorithm applied to each element without editing the element classes. You often use an Iterator to walk, and a Visitor to do something at each stop.

Iterator · Visitor. In .NET, IEnumerator<T> behind foreach is the Iterator pattern.

9 · Singleton vs static class vs DI-singleton lifetime

All three give you "just one of these in the whole app." But they differ enormously in testability, polymorphism, and who controls the lifetime — and this is where a lot of C# code goes wrong. Singleton is the most-abused pattern; usually what you actually want is the third option.

class Config {
    private static readonly Config _i = new();
    private Config() { }
    public static Config Instance => _i;   // callers reach in globally
    public string Env { get; set; } = "prod";
}
// Every caller hard-codes Config.Instance — a hidden dependency,
// awful to mock, easy to turn into global mutable state.

interface IConfig { string Env { get; } }
class Config : IConfig { public string Env => "prod"; }

// Register once; the container guarantees a single instance.
services.AddSingleton<IConfig, Config>();

// Consumers just ask for the interface — mockable, explicit:
class OrderService(IConfig config) { /* uses config.Env */ }

class Logger {
    private static readonly Lazy<Logger> _lazy = new(() => new Logger());
    public static Logger Instance => _lazy.Value;   // thread-safe, lazy
    private Logger() { }
}

Full Singleton treatment (and why it's over-used): Chapter 3.

10 · Chain of Responsibility vs Decorator

Both build a linked line of wrapper objects, each holding the next. Structurally, twins again. The behavioural difference is the whole thing: a Decorator always delegates to its inner object and adds something — every link runs. A Chain link may stop — it decides whether to handle the request itself and halt, or pass it along.

abstract class Approver {
    protected Approver? Next;
    public void SetNext(Approver n) => Next = n;
    public void Handle(Request r) {
        if (r.Amount <= Limit) Approve(r);   // handle...
        else Next?.Handle(r);                // ...or pass along. Not both.
    }
    protected abstract void Approve(Request r);
}

class CompressStream : IStream {
    private readonly IStream _inner;
    public CompressStream(IStream inner) => _inner = inner;
    public void Write(byte[] data) {
        var packed = Compress(data);
        _inner.Write(packed);                // ALWAYS calls inner, plus extra
    }
}

Chain of Responsibility · Decorator.

11 · MVC vs 3-tier

A frequent mix-up because both name "three things." But they live at different levels: 3-tier is about physical/deployment tiers (where code runs), while MVC is a design pattern for organising UI code (how responsibilities split within a tier). They are not alternatives — you can build MVC inside the presentation tier of a 3-tier system.

Full architectural treatment: 3-Tier and MVC in Chapter 8.

Edge-case quiz — "X or Y?"

Every question below is a deliberate edge case between two patterns from this page. Decide before you click, and say the litmus test out loud.