C# Design Patterns

Guidance for selecting and implementing design patterns in modern C#/.NET. Content is structured after refactoring.guru (intent, applicability, pros and cons) and dofactory (.NET-optimized variants that use framework features instead of hand-rolled GoF structure).

When to use

• Apply GoF design patterns idiomatically in C#. Problem shapes that call for one: object creation sprawl, switch-on-type logic, tight coupling, undo/redo, plugins.
• Not for architectural patterns like repository, CQRS or layering.

Core principles

1. Pattern selection comes from the problem, not the other way around. Never recommend a pattern because it is 'good practice'. Identify the design pain first, then check the selection table below. If no pain exists, no pattern is needed.
2. Prefer the .NET-native form. Many GoF patterns are already built into the framework or the language. Hand-rolling the classic UML structure when the platform provides it is an anti-pattern. The reference files mark these as '.NET-native form'.
3. Modern C# changes the implementation. Use DI containers, delegates, lambdas, generics, records, pattern matching, IObservable<T>, IEnumerable<T>/yield, and source generators where they replace boilerplate classes. Show the classic structure only when the user asks for it explicitly (e.g. for learning or interviews).
4. Always state the cost. Every pattern adds indirection. When recommending one, name the tradeoff in one or two sentences (more types, harder navigation, runtime overhead, etc.).
5. Style comes from csharp, not from here. All samples follow its conventions (primary constructors for dependency capture, properties before constructors, sealed by default). When generating real project code, load csharp alongside this skill; on any style conflict, csharp wins.

Workflow