Intro

GoF (Gang of Four) Design Patterns are 23 reusable solutions to recurring object-oriented design problems, first documented in Design Patterns: Elements of Reusable Object-Oriented Software (1994) by Gamma, Helm, Johnson, and Vlissides. They provide a shared vocabulary for design intent — when a team says “let’s use a Strategy here,” everyone immediately understands the tradeoffs without long explanations. Patterns are not copy-paste code; they’re templates for solving classes of problems. This section covers all 23 GoF patterns organized by category, each with production C# examples showing the problem without the pattern, the transformation with it, and the .NET built-ins that already implement it — connecting new knowledge to things you use daily.

Questions

How do you decide which GoF category a pattern belongs to?

Creational if the problem is about object construction — hiding how, when, or which type to instantiate. Structural if the problem is about composing classes or adapting interfaces into larger, more convenient structures. Behavioral if the problem is about assigning responsibility or defining the communication flow between objects.

• The category signals intent, not class structure: Proxy (Structural) and Decorator (Structural) look identical structurally but serve different behavioral intents.
• When in doubt: ask “Is this about making objects, assembling objects, or communicating between objects?”
• Tradeoff: categories help communicate design intent quickly, but the same structure can serve different intents — always explain the why, not just the pattern name.

When does using a design pattern become an anti-pattern?

When the variation it enables doesn’t exist yet and isn’t clearly anticipated. Patterns add abstractions — more classes, more indirection, harder debugging — and abstraction has a cost.

• Introduce a pattern at the second variation point (rule of three / YAGNI), not speculatively.
• Most common offenders: Singleton hiding shared mutable state, Factory Method for a class that never has variants, Builder for objects with 2 properties.
• Tradeoff: patterns pay off over time through extension without modification; they cost upfront in complexity. The break-even is when the second concrete variant appears or when the roadmap makes variation certain.

References

• Design Patterns playlist by Christopher Okharavi — must watch playlist for the design patterns.
• Refactoring.Guru — Design Patterns — comprehensive pattern catalog with intent, problem, solution, and C# examples for 22 GoF patterns (excludes Interpreter).
• Design Patterns: Elements of Reusable Object-Oriented Software (GoF) — the original 1994 book defining all 23 patterns; the authoritative primary source.
• Martin Fowler — Patterns of Enterprise Application Architecture — enterprise-level pattern catalog extending GoF into application architecture concerns; complements GoF for service and data layer design.
• Wikipedia — Software design pattern — overview of all 23 GoF patterns with intent summaries, the original categorization table, and historical context.