It’s also the largest family of the Gang of Four catalog: 11 of the 23 patterns in the 1994 book are behavioral, against five creational and seven structural. If creational patterns answer the question “how is an object born?” and structural patterns “how do objects fit together?”, behavioral patterns help us answer questions like:

• How do we change an algorithm at runtime without touching the code that uses it?
• How do we let many objects react to an event without the sender knowing who they are?
• How do we pass a request through a series of steps, each free to handle it or pass it on?
• How do we turn a request into an object that can be queued, logged or undone?
• How do we walk through a collection, or a tree, without exposing how it’s built?

But as often happens in .NET, the story of these patterns is also the story of the language. Many of them have been absorbed by C# and by the framework so deeply that we use them every day without calling them by name: foreach is an Iterator, event is an Observer, the ASP.NET Core middleware is a Chain of Responsibility.

In this series, we’ll explore the following behavioral patterns. As with the previous families, not just GoF:

• Chain of Responsibility Pattern (GoF): Passes a request along a chain of handlers, each of which can handle it or pass it to the next one
• Command Pattern (GoF): Turns a request into an object, so it can be queued, logged, retried or undone
• Interpreter Pattern (GoF): Represents the grammar of a small language as objects, and uses them to evaluate its sentences
• Iterator Pattern (GoF): Traverses the elements of a collection without exposing its internal structure
• Mediator Pattern (GoF): Centralizes the communication between objects, so they don’t refer to each other directly
• Memento Pattern (GoF): Captures the state of an object so it can be restored later, without breaking encapsulation
• Observer Pattern (GoF): Automatically notifies many dependent objects when the state of one object changes
• State Pattern (GoF): Lets an object change its behavior when its internal state changes, as if it changed class
• Strategy Pattern (GoF): Defines a family of interchangeable algorithms and lets the client choose one at runtime
• Template Method Pattern (GoF): Fixes the skeleton of an algorithm in a base class and lets subclasses redefine some of its steps
• Visitor Pattern (GoF): Adds new operations to a structure of objects without changing their classes
• Null Object Pattern: Replaces null with an object that does nothing, so the caller never has to check
• Specification Pattern: Encapsulates a business rule in an object that can be combined with others and reused, even in database queries
• Event Aggregator Pattern: Collects the events of many publishers in a single place, so subscribers register only once

Fourteen names are easier to keep in mind by the question each one answers:

Behavioral Basics: Inheritance or composition?

The Gang of Four split the family in two. Only the Template Method and the Interpreter are class patterns, built on inheritance; all the others are object patterns, built on composition: a Strategy is an object you plug in, an Observer one you register, a Command one you pass around. More than thirty years later, composition is the default, and in C# it has become much lighter than in the C++ of 1994, because the smallest possible object with a behavior is not a class. It’s a delegate.

You Already Use Them: Behavioral patterns inside .NET

Many behavioral patterns are already in the code we write every day:

• Iterator — IEnumerable<T>, foreach, yield return and IAsyncEnumerable<T>
• Observer — C# events, IObservable<T>, INotifyPropertyChanged, IOptionsMonitor<T>.OnChange
• Strategy — IComparer<T>, IEqualityComparer<T>, the Comparison<T> passed to List<T>.Sort
• Template Method — BackgroundService, where you write only ExecuteAsync
• Chain of Responsibility — the ASP.NET Core middleware and the DelegatingHandler of HttpClient
• Command — ICommand in WPF and .NET MAUI, with Execute and CanExecute
• Visitor — ExpressionVisitor in System.Linq.Expressions and the syntax walkers of Roslyn
• Interpreter — the regular expression engine, which interprets your pattern as a series of instructions
• Null Object — NullLogger<T>.Instance, Stream.Null, TextWriter.Null
• Specification — the Expression<Func<T, bool>> predicates that EF Core translates into SQL

The language took a long time to absorb them, one release at a time:

From Hierarchies to Delegates: The functional revolution

In their classic form, Strategy, Command and Template Method all require a small hierarchy: an interface or an abstract class, and one class per variant. Imagine calculating the shipping costs of an e-commerce site:

// Classic: one interface, one class per algorithm
public interface IShippingCostStrategy
{
    decimal Calculate(Order order);
}
 
public sealed class ExpressShipping : IShippingCostStrategy
{
    public decimal Calculate(Order order) => 9.90m + order.Items.Count * 0.50m;
}
 
// ... StandardShipping, PickupPoint, and one class for every new rule
 
// Modern: the algorithm is just a value
public sealed class CheckoutService(Func<Order, decimal> shippingCost)
{
    public decimal Total(Order order) => order.Total + shippingCost(order);
}
 
// Usage
var standard = new CheckoutService(o => o.Total >= 50m ? 0m : 4.90m);
var express = new CheckoutService(o => 9.90m + o.Items.Count * 0.50m);

With C# 3.0 came lambdas, and that was the watershed moment: a strategy with a single method is just a function, and a function can be passed, stored and composed like any other value. LINQ is built on this idea: OrderBy(o => o.Total) receives its sorting key as a strategy. The same happened to the Command (a Func<CancellationToken, Task> is a command waiting to be run) and to the Template Method: ASP.NET Core cookie authentication lets you customize a step of the flow with a delegate, such as options.Events.OnRedirectToLogin, with no subclass. (If you want to find out more about delegates, events and lambdas, click here.)

But beware! A lambda has no name and no dependencies of its own. When the algorithm needs services from the DI container, has more than one method, or must be chosen with a key read from the configuration, the class comes back. Keyed services, introduced in .NET 8, are the modern way to register ExpressShipping with the key "express" and inject it where it's needed. (If you want to find out more about keyed services, click here.)

What do you think? Have delegates replaced the classic Strategy in your code, or do you still prefer one class per algorithm? Leave a comment with your opinion.

Observer and Iterator: Events, streams and IAsyncEnumerable

C# embraced the Observer from day one: since C# 1.0, the event keyword and multicast delegates give every class a list of subscribers, with += and -= to join and leave it. In .NET Framework 4, IObservable<T> and IObserver<T> added what events lacked: the end of the stream (OnCompleted), its errors (OnError), and a subscription that is itself an IDisposable. On top of them, Reactive Extensions (the System.Reactive package) lets you filter, throttle and combine notifications like a LINQ query.

The pattern is everywhere, but it brings some insidious traps:

• a subscriber that never unsubscribes lives as long as the publisher: the classic memory leak of events;
• an exception in one handler stops the handlers after it;
• an async void handler throws exceptions that the publisher cannot catch.

The Iterator had a similar destiny. The GoF version required a dedicated class with First, Next, IsDone and CurrentItem. C# made it disappear: C# 1.0 gave us IEnumerable and foreach, C# 2.0 yield return, with the compiler writing the state machine for us. LINQ, in C# 3.0, is a chain of iterators that produce values only when someone asks for them: the famous deferred execution. The last step came with C# 8.0 and .NET Core 3.0: IAsyncEnumerable<T> and await foreach, iterators that can wait for I/O between one element and the next. Here's one that hides the pagination of a remote API:

public sealed class OrderFeed(HttpClient http)
{
    public async IAsyncEnumerable<OrderDto> ReadAllAsync(
        [EnumeratorCancellation] CancellationToken cancellationToken = default)
    {
        string? next = "orders?page=1";
 
        while (next is not null)
        {
            var page = await http.GetFromJsonAsync<OrderPage>(next, cancellationToken)
                ?? throw new InvalidOperationException("Empty response from the server");
 
            foreach (var order in page.Items)
            {
                yield return order; // the consumer sees orders, never pages
            }
 
            next = page.NextLink;
        }
    }
}

The consumer writes a simple await foreach and never sees a page. The [EnumeratorCancellation] attribute is the detail that makes the difference: the token passed with WithCancellation reaches the iterator, which stops between one page and the next. (If you want to find out more about async streams, click here.)

The Middleware Pipeline: Chain of Responsibility at the heart of ASP.NET Core

In the Decorator article, we saw that the ASP.NET Core pipeline is both a decorator and a chain of responsibility, and that the difference fits in one line: await next(context). (If you want to find out more about the Decorator, click here.) When a component can decide not to call it, it's a handler of a Chain of Responsibility:

// Each handler decides: handle the request, or pass it on
app.Use(async (context, next) =>
{
    if (app.Configuration.GetValue<bool>("Shop:Maintenance"))
    {
        context.Response.StatusCode = StatusCodes.Status503ServiceUnavailable;
        await context.Response.WriteAsync("The shop is under maintenance, please come back soon!");
        return; // short-circuit: the rest of the chain never runs
    }
 
    await next(context); // pass the request to the next handler
});
 
app.MapGet("/orders/{id}", (string id) => Results.Ok(new { id, status = "Confirmed" }));

Here’s the thing: the order is part of the design. A handler in the wrong position, or one that forgets to call next, silently changes the behavior of the whole application.

Pattern Matching and Closed Hierarchies: State and Visitor rethought

The Visitor is the most ceremonious of the GoF patterns: every class gets an Accept method, the visitor gets one Visit method per type, and the double dispatch is hard to explain on the first attempt. The framework still uses it where it makes sense: huge, open trees like expression trees and the Roslyn syntax tree.

For the hierarchies of our domain, pattern matching offers a more direct road. It arrived in C# 7.0 and grew with the switch expressions of C# 8.0 and the relational and logical patterns of C# 9: the operation lives in one switch expression over the types. The same applies to the State pattern, which classically spreads the state machine over one class per state. With records and tuple patterns, the transitions fit in one table:

public abstract record OrderState;
public sealed record Pending : OrderState;
public sealed record Paid(DateTimeOffset PaidAt) : OrderState;
public sealed record Shipped(string TrackingCode) : OrderState;
public sealed record Cancelled(string Reason) : OrderState;
 
public abstract record OrderEvent;
public sealed record PaymentReceived(DateTimeOffset At) : OrderEvent;
public sealed record ParcelShipped(string TrackingCode) : OrderEvent;
public sealed record CancelRequested(string Reason) : OrderEvent;
 
public static class OrderWorkflow
{
    // The whole state machine in one table
    public static OrderState Next(OrderState state, OrderEvent @event) => (state, @event) switch
    {
        (Pending, PaymentReceived p) => new Paid(p.At),
        (Paid, ParcelShipped s) => new Shipped(s.TrackingCode),
        (Pending or Paid, CancelRequested c) => new Cancelled(c.Reason),
        _ => throw new InvalidOperationException(
            $"Invalid transition: {state.GetType().Name} + {@event.GetType().Name}")
    };
}

The classic State is still the right choice when each state carries a lot of its own behavior. But when the transitions are the heart of the problem, the table is self-documenting: you read it, and you know the rules of the order.

The missing piece has always been exhaustiveness: with an open hierarchy, the compiler can’t know all the cases, and a _ arm can hide the ones we forgot. C# 15 addresses it with union types and closed hierarchies. A closed class can be derived only inside its own assembly, so the compiler knows every direct descendant, and a switch that handles all of them needs no default arm. C# 15 comes with .NET 11, which at the time of writing is a release candidate, with the release expected in November 2026: for now, it's a preview of what these hierarchies will look like. Union types, closed hierarchies and the whole history of pattern matching will each have their own C# Insights.

Mediators and Async: Behaviors that cross boundaries

The GoF Mediator was born for a dialog box: instead of letting every widget know all the others, they all talk to a director. In .NET the idea took a different shape: in-process mediators, where you send a request object and the mediator finds its handler. For years MediatR has been the reference library; in July 2025 its author announced commercial editions of MediatR and AutoMapper, a good moment to ask whether we need a mediator at all.

A mediator gives you one place for cross-cutting concerns, but the price is indirection: Go to Definition no longer takes you to the code that runs. The alternatives range from injecting the handler directly to mediator libraries based on source generators. The Event Aggregator applies the same idea to notifications, and when messages cross the boundary of the process, we enter the Integration patterns, a family of their own.

The GoF interfaces were synchronous: Execute(), Update(), HandleRequest(). Today almost every behavior does I/O: a strategy calls a payment API, a command writes to the database, an observer sends an email. Since C# 5.0, this has changed the shape of the whole family:

• Signatures — Task or ValueTask, with a CancellationToken as part of the contract
• Chains — the token flows through every link, and every link must respect it
• Observers — classic events don’t handle asynchronous work well, and async void is always around the corner

A behavior that ignores cancellation keeps working for a user who’s already gone. With .NET 11, Runtime Async (not final yet) moves async/await support into the runtime itself, for cleaner stack traces and lower overhead; it will have its own C# Insights.

Testability: Behaviors you can verify

Behavioral patterns are good friends of tests, because each of them extracts a piece of behavior into a replaceable unit. A strategy passed as a delegate needs no mock, just a lambda, and a state table is tested by feeding it events.

The most hidden collaborator of many behaviors is time: carts that expire, coupons that end, retries that wait. Since .NET 8, TimeProvider makes it injectable, and the FakeTimeProvider of the Microsoft.Extensions.TimeProvider.Testing package lets a test move it forward with Advance. But beware! The more indirection we add (events, mediators, long pipelines), the less a unit test tells us about the whole flow: decoupled behaviors need integration tests that put them back together.

Future Trends: Generated code and orchestrated behaviors

Two trends are reshaping this family. The first is source generators: behaviors once resolved at runtime with reflection are now resolved at build time. (If you want to find out more about source generators, click here.) The regular expression engine is the perfect example of an Interpreter that evolved: by default a pattern is interpreted at runtime, with RegexOptions.Compiled it becomes IL, and since .NET 7 [GeneratedRegex] turns it into C# during the build, code you can open and follow.

The second trend is AI agents. When a language model decides at runtime which tool to call, each call is a command that can be logged, approved by a human or rejected, and a chain of checks decides what actually runs. The patterns become the guardrails of a non-deterministic behavior.

What’s Next

Behavioral patterns have come a long way: from hand-written hierarchies to delegates, from iterator classes to yield return, from double dispatch to exhaustive switches. Many are now part of the language; others, like the Mediator, remain a design choice to be made with care. The key to success is the same as with the other families: use the language when it already solves the problem, and the pattern when it doesn't.

In the upcoming articles, we’ll explore each behavioral pattern individually, starting with the Chain of Responsibility.

Stay tuned.

Thanks for reading.

If you found this article helpful, follow me for the next ones or just clap.

Back to article Introduction to Design Patterns with C# .NET

Behavioral Patterns in .NET C#: Coordinating objects and responsibilities in modern applications was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.