A delegate is a variable that holds a method — so "what to do" can be decided somewhere else, and passed in like any other piece of data.

You already know how to write a method: CalculateTotal(), SendEmail(), Validate(). You call it by name, and it runs. But what if you don't know, at compile time, which method should run?

Imagine you're writing a button. When the user clicks it, something should happen — but a generic Button class has no idea what. Maybe it saves a file. Maybe it opens a dialog. Maybe it closes the app. The button's author can't hardcode any of that; they need a way to say "run whatever method the caller hands me."

That's the exact problem a delegate solves. In every language you've used so far, a method has been something you call. A delegate lets a method become something you can hold in a variable, pass as an argument, and call later — a value, just like an int or a string.

This lesson is your first real exposure to treating code itself as data — the idea that unlocks lambdas, events, and eventually LINQ.

What Is It?

The Simple Explanation

A delegate is a type that represents "a method with a particular shape" — a specific list of parameter types and a return type. A variable of that delegate type doesn't hold a number or a string; it holds a reference to a method. You can then call that method through the variable, without ever writing the method's real name at the call site.

People often describe a delegate as a "type-safe function pointer." That's a good starting mental picture: like a C function pointer, it lets you store and invoke a method indirectly — but unlike a raw pointer, the compiler checks that the method you assign actually matches the required signature.

The Technical Definition

In C#, a delegate type is declared with the delegate keyword. It describes a method signature — return type and parameters — but no body:

public delegate int MathOperation(int a, int b);

This single line defines a new type, MathOperation. Any method that takes two int parameters and returns an int is compatible with it — regardless of the method's actual name or which class it lives on. A variable of type MathOperation can be assigned any such method, and invoking the variable invokes whichever method it currently holds.

Why Does It Exist?

The Problem — Behavior You Can't Hardcode

Some code needs to run a piece of logic it doesn't own. Think about:

• A button that needs to run whatever the application wants when clicked.
• A sorting routine that needs to compare items in a way only the caller knows (by name? by price? by date?).
• A retry helper that needs to run "whatever operation might fail" and retry it.
• A notification system that needs to alert any number of interested parties, without knowing who they are in advance.

Without delegates, the only way to make code like this configurable is with interfaces (define an IComparer, implement a whole class just to wrap one method) or giant if/switch statements baked into the reusable code itself — which defeats the point of reusability.

The Solution — Pass the Method Itself

A delegate lets the caller hand over the actual behavior as a value. The reusable code doesn't need to know what the method does — only that it matches the expected signature. This is often called a callback: "call me back with this method when you're ready."

Big Picture

How It Works

public delegate int MathOperation(int a, int b);

static int Add(int a, int b) => a + b;

MathOperation operation = Add;

int result = operation(2, 3); // calls Add(2, 3) → 5

Simple Example

using System;

// 1. Declare the delegate type
public delegate int MathOperation(int a, int b);

class Program
{
    static int Add(int a, int b) => a + b;
    static int Multiply(int a, int b) => a * b;

    static void Main()
    {
        // 2. Assign a method to a delegate variable
        MathOperation operation = Add;
        Console.WriteLine(operation(2, 3)); // 5

        // 3. Reassign — same variable, different method
        operation = Multiply;
        Console.WriteLine(operation(2, 3)); // 6

        // 4. Pass the delegate into another method
        RunOperation(operation, 4, 5);
    }

    static void RunOperation(MathOperation op, int x, int y)
    {
        // This method has no idea whether it's adding, multiplying, or anything else.
        int result = op(x, y);
        Console.WriteLine($"Result: {result}");
    }
}

Code → Meaning → Result: operation doesn't know it's holding Add — it only knows it holds "some method that takes two ints and returns an int." Reassigning operation = Multiply instantly changes what operation(2, 3) does, with zero changes to RunOperation. That's the whole point: RunOperation is reusable for any matching behavior.

Real-World Example

Consider an order-processing pipeline that needs to run a "validation step" before saving. Different order types need different validation, but the processing method itself shouldn't need to change every time a new rule is added.

using System;

public delegate bool OrderValidator(decimal orderTotal);

public class OrderProcessor
{
    public void Process(decimal orderTotal, OrderValidator validate)
    {
        Console.WriteLine($"Processing order for {orderTotal:C}...");

        if (!validate(orderTotal))
        {
            Console.WriteLine("Order rejected by validation rule.");
            return;
        }

        Console.WriteLine("Order saved.");
    }
}

class Program
{
    static bool RejectIfOverCreditLimit(decimal total) => total <= 5000m;
    static bool RejectIfZeroOrNegative(decimal total) => total > 0m;

    static void Main()
    {
        var processor = new OrderProcessor();

        processor.Process(1200m, RejectIfOverCreditLimit); // passes
        processor.Process(9000m, RejectIfOverCreditLimit); // rejected
        processor.Process(1200m, RejectIfZeroOrNegative);  // passes — different rule, same Process method
    }
}

OrderProcessor.Process never needs to know which validation rule is being applied. New rules can be added anywhere in the codebase without ever touching OrderProcessor — a small taste of the flexibility that makes delegates so central to extensible design.

Analogy

Under the Hood

A delegate isn't a magic language trick — it's a real object.

Common Confusion

1. "A delegate is a method" — not quite

A delegate type describes a signature. A delegate variable holds a reference to a method that matches that signature. The method itself still lives wherever it was defined — the delegate is just a way to refer to it indirectly.

2. Assigning vs calling — the missing parentheses matter

operation = Add; assigns the method itself to the delegate. operation = Add(); would try to call Add immediately (and fails to compile here, since Add needs arguments) and assign its result — a completely different thing. Leaving off the parentheses is what tells the compiler "I mean the method, not its result."

3. Delegates vs interfaces — both express "a contract," differently

An interface with one method (like IComparer<T>) and a delegate can often solve the same problem. The difference: an interface requires a whole class to implement it; a delegate lets you point directly at any matching method — including one that already exists — without writing a wrapper class. As you'll see in the next lessons, C# leans heavily on delegates (and lambdas) for exactly this reason.

Common Mistakes

Mistake 1 — Invoking a delegate that was never assigned

A delegate variable that's still null throws a NullReferenceException the moment you try to invoke it — there's no method to call.

MathOperation operation = null;
operation(2, 3); //  NullReferenceException

Check for null first, or use the null-conditional invocation operator: operation?.Invoke(2, 3);.

Mistake 2 — Declaring a new custom delegate type for everything

Writing public delegate int MathOperation(int a, int b);, public delegate bool Validator(decimal d);, and dozens more like it clutters your codebase with near-identical types.

The BCL already ships generic delegate types — Action and Func — that cover almost every shape you'll need. You'll meet them in the next two lessons; custom delegates are still useful, but reach for them less often than you might expect.

Mistake 3 — Forgetting the method group has to match exactly

Trying to assign a method whose parameter or return types don't line up with the delegate's signature is a compile-time error — there's no implicit narrowing of parameter types.

Match the signature precisely (return type and parameter types, though parameter names don't need to match) — the compiler enforces this for you, which is exactly what makes delegates "type-safe."

When Should I Use It?

• Whenever a piece of code needs to run behavior it doesn't own — callbacks, custom sort/filter logic, pluggable strategies.
• As the foundation for events (covered later in this module) — every event is built on a delegate.
• When you need to understand framework code — ASP.NET Core middleware, LINQ, and UI event handlers are all delegate-based under the surface.

Mental Model

Key Takeaway

Check Your Understanding

You've seen what a delegate is and why it exists. Let's check your understanding before moving on to writing your own delegate types.

You now understand what a delegate is and why C# needs a way to treat methods as values. Next, you'll write your own custom delegate types and discover multicast delegates — the mechanism events are built on.

dotnetmadeeasy.com — Learn C# and .NET, the right way.