Design Patterns

A catalog of object-oriented design patterns with C# examples, illustrations, and honest tradeoffs.

Design patterns are proven solutions to recurring problems in object-oriented design. They are not code you copy and paste: they are structural recipes that you adapt to your domain, your language, and your team.

Coined by the Gang of Four in 1994, the 23 original patterns remain the common vocabulary for discussing software design. Knowing them doesn't automatically make you a better programmer, but it gives you a language to discuss decisions without drawing diagrams on a napkin.

#The problem

Without patterns, each recurring problem is solved manually and differently in every file. Classes become coupled to those who create them, if/else statements grow little by little until no one wants to touch them, and names cease to communicate intent: two developers look at the same code and see two different things. The result is permanent friction for changes that should be trivial.

#The solution

Design patterns provide structure and names to decisions. Instead of inventing a solution for each case, you rely on a proven recipe that your team already understands. Saying "this is a Strategy" or "here we use Observer" replaces a 30-line explanation and makes it clear what can be touched and what cannot without breaking the contract.

#When to use it

When you notice you're solving the same problem two or three times, with slightly different code.
When a class starts knowing too much about who creates it or who consumes it.
When you need to name a decision: "this is a Strategy" communicates more than 30 lines of explanation.

#When NOT to use it

To feel smart. A clear if/else trumps a premature Visitor.
In single-use code: scripts, prototypes, spikes.
When the pattern forces you to invent abstractions that do not exist in the domain.

#How this chapter is organized

The 23 classics are grouped according to the GoF by intent:

Creational — how objects are constructed (Singleton, Factory Method, Builder…).
Structural — how they assemble into larger structures (Adapter, Decorator, Composite…).
Behavioral — how responsibilities are distributed and they communicate (Strategy, Observer, State…).

When a pattern has more than one idiomatic form (for example, classic Singleton vs thread-safe Singleton), you will find them within /variants on their respective page.

#How to read each pattern

All pages follow the same script:

Context and problem — what situation motivates it.
Solution — the class structure / collaborations.
C# Example — idiomatic, not academic, code.
When NOT to apply it — because no pattern is free.
Tradeoffs — what you gain and what you pay for.

Looking for something tactical that the GoF doesn't cover? Check out Solution Patterns.
Are you currently deciding how to organize the entire app? Architecture Patterns.
Thinking about deployment? Deployment Styles.

Creational — How objects are created, hiding instantiation logic.
Structural — How classes and objects compose into larger, more flexible structures.
Behavioral — How objects interact and how responsibilities are distributed.