Roadmap › 1. .NET › Step 12
DP
Design Patterns (GoF + Enterprise) in C#
Creational, structural and behavioural Gang-of-Four patterns with C# code, plus Repository, Unit of Work, CQRS, Mediator, Options and microservice patterns.
Quick revision for interview day. Print it or save it as a PDF.
23 GoF patterns — one line each
| Pattern | One line |
|---|---|
| Singleton | One instance (Lazy<T> / AddSingleton) |
| Factory Method | Subclass/method decides concrete type |
| Abstract Factory | Family of related objects |
| Builder | Step-by-step construction, fluent |
| Prototype | Clone existing object |
| Adapter | Convert interface (wrap SDK) |
| Bridge | Split abstraction from implementation |
| Composite | Tree; leaf and group treated alike |
| Decorator | Wrap to add behaviour, same interface |
| Facade | Simple API over subsystem |
| Flyweight | Share immutable state |
| Proxy | Stand-in controlling access (lazy, remote, auth) |
| Chain of Responsibility | Pass along handlers (middleware) |
| Command | Request as object (queue, undo) |
| Interpreter | Evaluate a grammar |
| Iterator | Sequential access (IEnumerable) |
| Mediator | Central communication (MediatR) |
| Memento | Snapshot/restore state |
| Observer | Subscribe/notify (events) |
| State | Behaviour depends on state object |
| Strategy | Interchangeable algorithms |
| Template Method | Base skeleton, subclass steps |
| Visitor | New operations without changing classes |
Patterns hiding in .NET
| .NET feature | Pattern |
|---|---|
Middleware, DelegatingHandler | Chain of Responsibility |
IHttpClientFactory, ILoggerFactory | Factory |
WebApplication.CreateBuilder | Builder |
Stream wrappers | Decorator |
event / IObservable | Observer |
IEnumerable + yield | Iterator |
DbContext / DbSet | Unit of Work / Repository |
| EF lazy-loading proxies | Proxy |
IComparer<T> | Strategy |
ExpressionVisitor | Visitor |
Enterprise/cloud
- Repository + UoW — data access abstraction + one transaction.
- CQRS — separate reads and writes.
- Outbox — event + data in the same transaction.
- Saga — distributed transaction with compensation.
- Retry / Circuit Breaker / Timeout / Bulkhead — resilience (
AddStandardResilienceHandler). - Options — typed config:
IOptions/IOptionsSnapshot/IOptionsMonitor. - Strangler Fig — replace a legacy system piece by piece.
- API Gateway / BFF — single entry point per client type.
Answer formula
Problem → pattern name → how it works (2 lines) → code shape (interface + classes) → where you used it → trade-off.
Which pattern for which problem?
| Problem in the interview question | Pattern |
|---|---|
Big switch on type / many interchangeable algorithms | Strategy |
| Add caching/logging/retry without touching a class | Decorator |
| Wrap a third-party SDK behind your own interface | Adapter |
| One simple call over many subsystems | Facade |
| Object creation varies by input/config | Factory Method / Abstract Factory |
| Complex object with many optional parts | Builder |
| Exactly one shared instance | Singleton (prefer AddSingleton) |
| Notify many listeners of changes | Observer / events |
| Request passes through a series of handlers | Chain of Responsibility |
| Behaviour depends on the object's state | State |
| Fixed algorithm with customisable steps | Template Method |
| Decouple senders and handlers (CQRS) | Mediator / Command |
| Reliable event publishing with DB writes | Outbox |
| Flaky downstream service | Retry + Circuit Breaker |