A design pattern is a named, proven solution to a design problem that keeps recurring.

That definition is doing two jobs, so let’s take them separately. Named means the solution has a label other developers already know. That turns a paragraph of explanation into one word in a code review. Recurring means somebody already hit this problem, solved it, and the solution held up well enough that it was worth writing down.

What a pattern is not is a snippet we paste. There is no Strategy class waiting in a NuGet package. A pattern describes how a few classes relate to each other. We write those classes ourselves, in the shape our own problem needs.

What They Look Like in C#

Most of the patterns in this course reach you through three mechanisms you already use.

Interfaces that separate a contract from its implementations. The moment we depend on IPaymentProcessor rather than StripeProcessor, we can hand the caller a different implementation without touching it. Half the patterns here are variations on that one move.

Composition instead of inheritance. One object holding another and delegating to it, rather than inheriting from it. This buys us combinations we choose at runtime instead of combinations we enumerate at compile time.

Inversion of control. Handing an object its dependencies rather than letting it construct them. Every time we register a service in ASP.NET Core’s container, we are applying a pattern this course names.

Why the Names Matter

The practical payoff of a pattern is usually the name rather than the mechanism.

A developer reading a class called OrderNotificationDecorator knows three things before opening it. It wraps another notifier. It can be stacked. It did not modify anything to exist. Three facts and no reading, because the name carries them.

That is also why we spend time recognising patterns in code we did not write. A great deal of .NET is built from these, and the names are our fastest way in.

How to Read This Course

Each lesson stands alone. You can read them in order, or open the pattern you need today and ignore the rest, then come back in three months for another one. Nothing in a lesson depends on your having read the lesson before it.

Every pattern lesson we wrote follows one shape. We show the problem in real code, then the pattern that fixes it, then our refactoring. After that come the places .NET already uses it, the mistakes people make, and the trade-offs. Once you know that shape, you can jump straight to the section you want.

Next, we look at what patterns actually buy you on a real codebase.