Design patterns in C#: Behavioral, creational, and structural

Design patterns are reusable and customizable solutions to problems that often arise in software design and development. The patterns you use and how you use them depend entirely on your own unique programs and problems. Learning design patterns will not only help you solve software design problems, but will make you a stronger developer and allow you and your team to communicate more efficiently and uniformly. Today, we’re going to take a look at some design patterns in C# and discuss their use cases and pros and cons.

What is a design pattern?#

Design patterns were made to tackle common problems that arise within software design and software development when working with real-world app development. Design patterns are like customizable templates that can be applied to your code regardless of your preferred programming language. While they aren’t meant to be directly copied and pasted into your code, they provide you with high-level conceptual information that can help you solve your software design problems.

The same design pattern won’t look the same when applied to two different programs. This is where the customization comes in. You can think of a design pattern as a blueprint, providing you a high-level plan to guide you through your software design process, but giving you the power to implement the solution in a way that best fits your needs.

Note: Design patterns are different from algorithms. Algorithms clearly define a set of steps to help you solve a problem, while design patterns provide high-level descriptions.

Why use design patterns?#

There are many benefits to using design patterns within your software development environment. Some benefits include:

• They provide you with a set of dependable solutions to common problems
• They help you learn the fundamentals to solving problems
• They give you and your team a way to communicate with one another more efficiently
• They provide you with pre-made templates that you can customize according to your needs
• They are easy to maintain because they mitigate the variability that arises with system requirements

There are 23 Gang of Four (GoF) patterns that are considered the foundations for all other design patterns. They are separated into three main groups based on three common problem areas within software architecture: behavioral, creational, and structural.

There are many different types of design patterns that you can implement into your programs. Let’s take a look at nine of the 23 GoF design patterns in C# and .NET and discuss their use cases and pros and cons.

Quick map: patterns ↔ C# language features#

Design patterns in C# are most useful when you lean on the language’s strengths:

• Interfaces & delegates → enable Strategy, Observer, Command, Template Method without inheritance tangles.

• Events → a natural fit for Observer; publisher raises events, subscribers handle them.

• Async/await → pair well with Command (asynchronous commands) and Chain of Responsibility (short-circuiting async handlers).

• Records (C# 9+) → handy for immutable Product types in Builder/Factory Method pipelines.

• DI containers (e.g., built-in .NET DI) → reduce friction for Abstract Factory, Strategy, Bridge, Proxy.

• Structs & Span → useful for Flyweight-like memory-sensitive designs (careful with copying semantics).

Keep this mapping in mind as you implement patterns; you’ll often replace deep inheritance with interfaces + DI + small objects.

Behavioral design patterns#

Behavioral design patterns are concerned with algorithms and assigning responsibilities to objects. First, we’ll take a look at the Chain of Responsibility design pattern.

Chain of Responsibility#

The Chain of Responsibility pattern enables you to pass requests along a chain of handlers. When a handler receives a request, it decides whether to process the request or pass it to the next handler in the chain.

Use cases

Here are some use cases of the Chain of Responsibility design pattern:

• Your set of handlers and their order are supposed to change at runtime
• You need to execute multiple handlers in a certain order
• Your program needs to process different types of requests in different ways, but you don’t know exact requests before

Command#

The Command pattern turns requests into stand-alone objects containing all the information about the requests. This process allows you to:

• pass requests as method arguments
• delay or queue requests to be executed
• reverse previous operations

Note: You can use the Prototype design patterns if you need to save copies of your Commands.

Use cases

Here are some use cases of the Command design pattern:

• You want to queue or schedule the execution of your operations, or you want to execute your operations remotely
• You want to reverse previous operations
• You want to configure objects with operations

Iterator#

The Iterator pattern allows you to iterate through elements in a collection without exposing the underlying representation.

Use cases

Here are some use cases of the Iterator design pattern:

• Your collection consists of complex data structures underneath, but you don’t want clients to see its complexity
• You want to reduce duplication of traversal code within your application
• You want to iterate through different data structures or the types of these structures are unknown to you before

Behavioral — More patterns to know#

Strategy#

Swap algorithms at runtime (e.g., different pricing policies).

public interface IPricing { decimal Calculate(decimal baseFare); }
public class SurgePricing : IPricing { public decimal Calculate(decimal baseFare) => baseFare * 1.5m; }
public class RideService(IPricing pricing) { public decimal Quote(decimal fare) => pricing.Calculate(fare); }

Observer#

Event-driven updates; use events for idiomatic C#.

public class Meter
{
    public event EventHandler<decimal>? FareChanged;
    public void Tick(decimal fare) => FareChanged?.Invoke(this, fare);
}

State#

Simplify sprawling if/else logic by delegating behavior to state objects.

Mediator#

Centralize complex UI/module interactions to reduce coupling.

Template Method#

Define algorithm steps in a base class; override steps in subclasses.

When to pick:
You’re toggling behavior at runtime (Strategy), broadcasting changes (Observer),
or taming conditional explosions (State, Mediator, Template).

Creational design patterns#

Creational design patterns provide you with different object creation mechanisms to increase the flexibility and reusability of your code. We’re going to take a look at three common creational design patterns, starting with the Abstract Factory design pattern.

Abstract Factory#

The Abstract Factory pattern allows you to create families of related objects without indicating their concrete classes.

Use cases

Here are some use cases of the Abstract Factory design pattern:

• You need your code to work with families of related objects, but you don’t want your code to rely on concrete classes
• You want to extend or customize your standard components

Builder#

The Builder pattern allows you to build complex objects one step at a time and produce different representations of an object using the same construction code.

Use cases

Here are some use cases of the Builder design pattern:

• You want to be able to create different representations of objects
• You want to build complex objects
• You don’t want to cram multiple parameters into your constructors

Factory Method#

The Factory Method pattern allows you to create objects in a superclass and allows subclasses to change the type of objects that will be created. It’s a specialization of the Template Method, which defines the framework of an algorithm in a superclass and allows the subclasses to override steps of the algorithm without changing the framework.

Use cases

Here are some use cases of the Factory Method design pattern:

• You don’t know the types and dependencies of objects your code works with
• You want to save your system’s resources and reuse existing objects instead of creating new ones
• You want to provide your library to users with the option to add to its components
• You need a lot of flexibility in your code

Creational — More patterns to know#

Singleton (with thread safety)#

public sealed class AppConfig
{
    private static readonly Lazy<AppConfig> _i = new(() => new AppConfig());
    public static AppConfig Instance => _i.Value;   // Lazy, thread-safe
    private AppConfig() {}
}

Tip: Prefer DI-scoped singletons over global statics to keep code testable.

Prototype#

Clone graph objects (implement ICloneable or custom deep copy).

Object Pool (non-GoF, but popular)#

Reuse expensive objects (e.g., buffers, HttpClient handlers).

When to pick:
You need one shared service (Singleton via DI), many similar instances quickly (Prototype),
or must reuse scarce resources (Pool).

Structural design patterns#

Adapter#

The Adapter pattern enables collaboration between objects with different interfaces.

Use cases

Here are some use cases of the Adapter design pattern:

• You want to use an existing class but its interface isn’t compatible with your existing code
• You want to reuse existing subclasses that lack common functionality and can’t be added to the superclass
• You want your legacy code to work with modern classes

Bridge#

The Bridge pattern allows you to split large classes or sets of related classes into separate hierarchies that can be developed independently of one another.

Use cases

Here are some use cases of the Bridge design pattern:

• You want to divide and organize a class with multiple versions of a specific functionality
• You want to extend a class in multiple independent ways
• You’re working with a cross-platform application or with multiple API providers

Composite#

The Composite pattern allows you to make objects into tree structures and work with those tree structures as individual objects.

Use cases

Here are some use cases of the Composite design pattern:

• You need to work with tree-like structures
• You want the client code to treat simple and complex elements in the same way

Structural — More patterns to know#

Facade#

Provide a clean API over complex subsystems (e.g., PaymentsFacade wrapping gateways).

Proxy#

Lazy-load or guard access (virtual proxy, caching proxy, security proxy).

Decorator#

Add cross-cutting behavior (logging, metrics, caching) without subclass explosion.

public interface IRepository { Task<Order?> GetAsync(Guid id); }
public class CachingRepo(IRepository inner, IMemoryCache cache) : IRepository
{
    public async Task<Order?> GetAsync(Guid id) =>
        await cache.GetOrCreateAsync(id, _ => inner.GetAsync(id));
}

Flyweight#

Share intrinsic state to reduce allocations (use with care; measure!).

When to pick:
You want a simpler facade, a protective or lazy layer (Proxy),
or to attach behavior orthogonally (Decorator).

Choosing the right pattern (a quick guide)#

When you’re unsure which design patterns in C# to apply, start from the symptom:

• Too many if/else or switch on type? → Strategy, State, Template Method.

• Tight coupling between modules? → Mediator, Observer, Facade, Bridge.

• Difficult object creation (many params / variants)? → Builder, Factory Method, Abstract Factory.

• Cross-cutting concerns (logging, caching, retries)? → Decorator, Proxy (+ Polly for resilience).

• Performance/memory pressure? → consider Flyweight, pooling, and measure with dotTrace/PerfView.

Rule of thumb: prefer composition over inheritance, surface interfaces for testability, and let DI wire concrete choices.

Testing & DI tips (keep patterns practical)#

Design patterns in C# shine when they’re easy to test:

• Program to interfaces: every collaborator in your pattern (strategy, handler, proxy) should be an interface to enable mocking.

• Use constructor injection for pattern participants; avoid service locators.

• Prefer stateless services when possible; they’re simpler to reason about and reuse in patterns like Command or Strategy.

• For Singleton, avoid global statics—register as Singleton in the DI container and inject where needed.

• For Observer, keep event handlers small and resilient; if work is heavy or remote, hand off to a queue.

Next steps for your learning#

C# design patterns provide you with customizable and reusable solutions to common software design problems. The patterns you will work with will be dependent upon your individual needs and programs. Once you learn more about the different design patterns, you can begin implementing them into your programs. There are many more design patterns to learn such as:

• Memento

• Prototype

• Singleton design pattern

• Decorator

• Flyweight

• Constructor

To learn more about fundamentals of C#, check out Educative’s course C# for Programmers: A Practical Guide. In this hands-on course, you’ll start with learning the “Hello World!” in C#, and then move into more advanced concepts like classes, inheritance, interfaces, and delegates. By the end, you’ll feel confident using C# in your next project.

Pitfalls & anti-patterns in C##

• Singleton everything: over-using singletons creates hidden dependencies and makes tests brittle. Reach for DI scopes instead.

• Inheritance-first designs: many GoF examples use inheritance; in modern C#, interfaces + composition are usually cleaner.

• Decorator bloat: too many nested decorators can obscure behavior. Prefer explicit composition or a small pipeline with named steps.

• Proxy vs. performance: every indirection adds overhead; measure with BenchmarkDotNet.

• Flyweight misuse: sharing to “save memory” can backfire via boxing, copying structs, or cache misses; profile real workloads.

• Async gotchas: if your pattern participants do I/O, make their interfaces Task-based to avoid sync-over-async deadlocks.

Happy learning!

Continue learning about system design and C##

• System Design Primer: learn the basics of system design
• Crack the top 45 C# data structure questions
• Systems Design Interview Guide: tips from an industry expert