Understanding Delegates vs Events in C#: When and How to Use Each

Introduction to Delegates and Events

If you’ve been coding in C# for a while, you’ve probably encountered delegates and events. These two features are incredibly powerful tools that help us write flexible, loosely coupled code. While they might seem similar at first glance (and yes, events are actually built on top of delegates), they each have their own purpose and best use cases.

I remember when I first started learning C#, I found it challenging to understand exactly when to use delegates versus events. Over time, I’ve realized that choosing the right tool can make a huge difference in how maintainable and flexible your code becomes.

In this article, I’ll walk you through delegates and events, highlight their key differences, and share practical examples that should help clear up when to use each one in your own projects.

What Are Delegates?

Let’s start with delegates. You can think of delegates in C# as type-safe function pointers. But what does that really mean? Simply put, delegates let you pass methods around like variables. You can reference a method, store it, pass it to other methods, and invoke it when needed. This enables powerful callback mechanisms and makes your code much more flexible.

How Delegates Work

Think of a delegate as a contract that says, “Any method that matches this signature can be assigned to me.” When you define a delegate, you’re specifying the return type and parameters that compatible methods must have. It’s like creating a template for what kind of methods can be referenced.

Here’s a basic delegate declaration:

// Declare a delegate type
public delegate int Calculator(int x, int y);

// Methods that match the delegate signature
public static int Add(int a, int b) => a + b;
public static int Subtract(int a, int b) => a - b;

// Using the delegate
Calculator calc = Add;
int result = calc(10, 5); // result = 15

// Changing the behavior by assigning a different method
calc = Subtract;
result = calc(10, 5); // result = 5

This simple example demonstrates how delegates provide a way to swap out implementations at runtime, making your code more flexible.

Built-in Delegate Types

You’ll be happy to know that you don’t need to define custom delegate types for every scenario. The .NET Framework comes with several built-in delegate types that cover most common cases:

Action<T…>: For methods that don’t return anything (void) and can take up to 16 parameters.
Func<T…, TResult>: For methods that return a value and can take up to 16 input parameters.
Predicate: A special case for methods that take one parameter and return a boolean (essentially a test condition).

These built-in types make your code cleaner and more standardized. Let me show you how they look in practice:

// Using built-in delegates
Action<string> logMessage = message => Console.WriteLine($"Log: {message}");
logMessage("Operation completed");

Func<int, int, int> multiply = (x, y) => x * y;
int product = multiply(4, 5); // product = 20

Predicate<string> isLongString = text => text.Length > 10;
bool isLong = isLongString("Hello, World!"); // true

Multicast Delegates

Here’s where delegates get really interesting. Did you know a single delegate can reference multiple methods? When you invoke that delegate, all the methods in its list get called one after another. This feature, known as multicast delegates, is incredibly useful for scenarios where you need to notify multiple handlers:

Action<string> notify = null;

// Add methods to the invocation list
notify += message => Console.WriteLine($"Email: {message}");
notify += message => Console.WriteLine($"SMS: {message}");
notify += message => Console.WriteLine($"Push notification: {message}");

// This will call all three methods in sequence
notify?.Invoke("System update scheduled");

The += operator adds a method to the delegate’s invocation list, and the -= operator removes a method.

What Are Events?

Now, let’s talk about events. If delegates are the technology, events are a specialized application of that technology. Events are built on top of delegates but with a specific purpose: implementing the Observer pattern. They provide a standardized way for one class (the publisher) to notify other classes (the subscribers) when something interesting happens.

Understanding Events

You can think of an event as a delegate with special access rules. While anybody with access to a delegate can invoke it directly, events can only be triggered from within the class that defines them. External classes can only subscribe or unsubscribe. This controlled access is what makes events perfect for building robust notification systems.

Here’s how to declare and use an event:

public class OrderProcessor
{
    // Define the event using a delegate type
    public event EventHandler<OrderEventArgs> OrderProcessed;

    public void ProcessOrder(Order order)
    {
        // Process the order...
        Console.WriteLine($"Processing order #{order.Id}");

        // Notify subscribers when processing is complete
        OnOrderProcessed(new OrderEventArgs(order));
    }

    // Protected method to raise the event
    protected virtual void OnOrderProcessed(OrderEventArgs e)
    {
        // Check if there are any subscribers before raising the event
        OrderProcessed?.Invoke(this, e);
    }
}

// Custom EventArgs class to pass data with the event
public class OrderEventArgs : EventArgs
{
    public Order Order { get; }

    public OrderEventArgs(Order order)
    {
        Order = order;
    }
}

// Usage
OrderProcessor processor = new OrderProcessor();

// Subscribe to the event
processor.OrderProcessed += (sender, e) =>
{
    Console.WriteLine($"Order #{e.Order.Id} has been processed");
    // Send an email confirmation, etc.
};

// Trigger the event
processor.ProcessOrder(new Order { Id = 12345 });

In this example, the OrderProcessor class publishes an event that notifies subscribers when an order has been processed. The subscriber registers its interest by attaching an event handler to the event.

Standard Event Pattern

Over time, the .NET Framework has established a standard way to work with events that you’ll see throughout the framework and in well-designed C# code:

Events are typically declared using the EventHandler<TEventArgs> delegate type
Event handlers follow a consistent signature: void EventHandler(object sender, TEventArgs e)
The sender parameter tells you which object raised the event
Custom event data is neatly packaged in a class that inherits from EventArgs

Following this pattern makes your code instantly familiar to other C# developers and ensures consistency across your application. Trust me, your future self and teammates will thank you for sticking to these conventions!

Key Differences Between Delegates and Events

Now that we’ve covered the basics of both delegates and events, let’s highlight their key differences. Understanding these distinctions will help you choose the right tool for each situation:

1. Access Control

Delegates: Think of delegates as open invitations. Anyone with access to a delegate variable can call the methods it points to, add new methods to the list, or even replace the entire list.

Events: Events are more like controlled notifications. Only the class that declares an event can trigger it. Outside classes can only subscribe or unsubscribe using the += and -= operators, giving the publishing class full control over when notifications happen.

2. Intended Purpose

Delegates: These are your general-purpose function pointers. They’re great for passing behavior as arguments, implementing strategy patterns, creating callbacks, and defining asynchronous operations.

Events: Events have a more focused purpose. They’re specifically designed for notification scenarios where one object needs to alert others when something happens, without needing to know who’s listening.

3. Invocation Control

Delegates: With a delegate, any code that can see it can trigger all the methods in its invocation list.

Events: Only the declaring class holds the keys to triggering an event. This encapsulation is crucial for maintaining the integrity of the publish-subscribe model.

4. Method Assignment

Delegates: You can directly assign methods to delegates using the = operator, completely replacing any previous assignments.

Events: You can’t directly assign to events. Instead, you must use += to subscribe and -= to unsubscribe, which preserves the multicast nature of the underlying delegate.

When to Use Delegates vs Events

So when should you use delegates, and when should you reach for events? The answer depends on what you’re trying to accomplish. Let me share some guidelines I’ve found helpful:

Use Delegates When:

You need return values: One big advantage of delegates is that they can return values, while event handlers are typically void. This makes delegates perfect for validation, transformation, or computation scenarios.
```
Func<string, bool> validator = text => !string.IsNullOrEmpty(text);
bool isValid = validator("Hello");   // We get back a result!
```

You need callback functionality: Delegates shine when you need to pass behavior as an argument, allowing the receiving method to call back to your code.

public void ProcessData(List<int> data, Func<int, bool> filter)
{
    foreach (var item in data)
    {
        if (filter(item))
        {
            Console.WriteLine($"Processed: {item}");
        }
    }
}

// Usage -> we're passing filtering logic as a parameter
ProcessData(new List<int> { 1, 2, 3, 4, 5 }, n => n % 2 == 0);

The caller needs to control when the callback happens: Delegates are great when you want the calling code to decide exactly when to invoke a method.
The callback is customized per call: When you need different behavior for each call, delegates let you pass in exactly the functionality you need.

Use Events When:

Multiple subscribers might be interested: Events are perfect when you don’t know in advance how many components will need to be notified. Your publishing class can just raise the event, and any number of subscribers can listen.

You want to restrict invocation: If you need to ensure only your class can trigger notifications, events provide that protection by design.

public class StockMonitor
{
    public event EventHandler<StockPriceChangedEventArgs> PriceChanged;

    // Only this class can trigger the event
    private void OnPriceChanged(Stock stock, decimal oldPrice, decimal newPrice)
    {
        PriceChanged?.Invoke(this, new StockPriceChangedEventArgs(stock, oldPrice, newPrice));
    }
}

You’re implementing the Observer pattern: If your design follows the classic publisher-subscriber model where objects need to be notified of changes in another object, events are tailor-made for this.
You want a standardized notification system: Events in C# come with established patterns that make your notification system immediately understandable to other developers.

Practical Example: Building a Notification System

Let’s create a more comprehensive example that illustrates when to use delegates versus events in a real-world scenario: a notification system that processes messages and distributes them to various channels.

The Delegate Approach: Message Processors

First, let’s define message processing using delegates, where different processing strategies can be plugged in:

public class Message
{
    public string Content { get; set; }
    public string Sender { get; set; }
    public DateTime Timestamp { get; set; }
    public MessagePriority Priority { get; set; }
}

public enum MessagePriority { Low, Normal, High, Critical }

public class MessageProcessor
{
    // Define delegate types for message processing
    public delegate bool MessageValidator(Message message);
    public delegate Message MessageTransformer(Message message);
    public delegate void MessageSender(Message message);

    // Store the processing pipeline components
    private readonly MessageValidator _validator;
    private readonly MessageTransformer _transformer;
    private readonly MessageSender _sender;

    // Configure the processing pipeline through constructor injection
    public MessageProcessor(MessageValidator validator,
                           MessageTransformer transformer,
                           MessageSender sender)
    {
        _validator = validator ?? throw new ArgumentNullException(nameof(validator));
        _transformer = transformer ?? throw new ArgumentNullException(nameof(transformer));
        _sender = sender ?? throw new ArgumentNullException(nameof(sender));
    }

    // Process a message through the pipeline
    public void ProcessMessage(Message message)
    {
        if (_validator(message))
        {
            var transformedMessage = _transformer(message);
            _sender(transformedMessage);
        }
        else
        {
            Console.WriteLine($"Message from {message.Sender} failed validation");
        }
    }
}

This approach uses delegates to create a flexible message processing pipeline where each step (validation, transformation, sending) can be customized.

The Event Approach: Notification System

Now, let’s use events to implement a notification system that allows multiple subscribers to react to messages:

public class NotificationSystem
{
    // Define events for different priority levels
    public event EventHandler<MessageEventArgs> MessageReceived;
    public event EventHandler<MessageEventArgs> HighPriorityMessageReceived;
    public event EventHandler<MessageEventArgs> CriticalMessageReceived;

    // Process an incoming message and notify appropriate subscribers
    public void ProcessIncomingMessage(Message message)
    {
        // Log all messages
        Console.WriteLine($"Message received at {DateTime.Now}: {message.Content}");

        // Notify general subscribers
        OnMessageReceived(message);

        // Notify specific subscribers based on priority
        if (message.Priority >= MessagePriority.High)
        {
            OnHighPriorityMessageReceived(message);
        }

        if (message.Priority == MessagePriority.Critical)
        {
            OnCriticalMessageReceived(message);
        }
    }

    // Protected methods to raise events
    protected virtual void OnMessageReceived(Message message)
    {
        MessageReceived?.Invoke(this, new MessageEventArgs(message));
    }

    protected virtual void OnHighPriorityMessageReceived(Message message)
    {
        HighPriorityMessageReceived?.Invoke(this, new MessageEventArgs(message));
    }

    protected virtual void OnCriticalMessageReceived(Message message)
    {
        CriticalMessageReceived?.Invoke(this, new MessageEventArgs(message));
    }
}

// Custom EventArgs class for message events
public class MessageEventArgs : EventArgs
{
    public Message Message { get; }

    public MessageEventArgs(Message message)
    {
        Message = message;
    }
}

This approach uses events to allow multiple systems to subscribe to notifications about messages at different priority levels.

Combining Both Approaches

In a real application, you might use both approaches together:

// Main program
public class NotificationProgram
{
    public static void Main()
    {
        // Create message processor with custom behaviors using delegates
        var processor = new MessageProcessor(
            // Validator delegate
            message => !string.IsNullOrEmpty(message.Content),

            // Transformer delegate
            message =>
            {
                // Add timestamp if missing
                if (message.Timestamp == default)
                    message.Timestamp = DateTime.Now;
                return message;
            },

            // Sender delegate -> connects to the notification system
            message => notificationSystem.ProcessIncomingMessage(message)
        );

        // Create notification system
        var notificationSystem = new NotificationSystem();

        // Subscribe to events with different handlers
        notificationSystem.MessageReceived += (sender, e) =>
            Console.WriteLine($"Standard handler: {e.Message.Content}");

        notificationSystem.HighPriorityMessageReceived += (sender, e) =>
            Console.WriteLine($"HIGH PRIORITY: {e.Message.Content}");

        notificationSystem.CriticalMessageReceived += (sender, e) =>
        {
            Console.WriteLine($"!!! CRITICAL !!! {e.Message.Content}");
            // Send SMS, trigger alarms, etc.
        };

        // Process some messages
        processor.ProcessMessage(new Message
        {
            Content = "System running normally",
            Sender = "System Monitor",
            Priority = MessagePriority.Normal
        });

        processor.ProcessMessage(new Message
        {
            Content = "Disk space low",
            Sender = "Storage Monitor",
            Priority = MessagePriority.High
        });

        processor.ProcessMessage(new Message
        {
            Content = "DATABASE DOWN!",
            Sender = "Database Monitor",
            Priority = MessagePriority.Critical
        });
    }
}

This example demonstrates:

Delegates are used to customize the behavior of the message processor through composable functions.
Events are used to enable multiple systems to subscribe to different types of notifications.

Best Practices

Over the years, I’ve learned some valuable lessons about working with delegates and events. Here are some best practices I’d recommend:

For Delegates:

Stick with built-in delegate types whenever possible. The Action, Func, and Predicate types cover most scenarios and make your code more consistent.
Always null-check your delegates before invoking them. The ?.Invoke() pattern is your friend here and will save you from those dreaded NullReferenceExceptions.
Be careful with parameters in multicast delegates. Ideally, use immutable parameters to avoid one delegate call affecting the next one in the chain.
Watch out for thread safety issues, especially if your delegates might be invoked from different threads. Proper synchronization is crucial!

For Events:

Embrace the standard event pattern with EventHandler<TEventArgs>. It’s familiar to other developers and follows established conventions.
Raise events through protected virtual methods (typically named “OnEventName”). This pattern allows derived classes to override the event raising behavior if needed.
Always check for null subscribers using the ?.Invoke() syntax before raising events.
Design your EventArgs classes to be immutable when possible. This prevents one subscriber from changing data that another subscriber might see.
Be extra cautious with async event handlers. They can lead to unexpected behavior and potential deadlocks if not carefully managed.

Common Pitfalls and Solutions

Let’s talk about some traps that even experienced developers can fall into when working with delegates and events.

Memory Leaks

The most common headache I’ve seen with events is memory leaks caused by forgotten subscriptions. Here’s what happens:

public class MemoryLeakExample
{
    public class Publisher
    {
        public event EventHandler SomeEvent;

        public void RaiseEvent()
        {
            SomeEvent?.Invoke(this, EventArgs.Empty);
        }
    }

    public class Subscriber
    {
        private readonly Publisher _publisher;

        public Subscriber(Publisher publisher)
        {
            _publisher = publisher;
            // We subscribe to the event here...
            _publisher.SomeEvent += OnSomeEvent;
        }

        private void OnSomeEvent(object sender, EventArgs e)
        {
            Console.WriteLine("Event received");
        }

        // But if this method is never called, we leak memory!
        public void Cleanup()
        {
            _publisher.SomeEvent -= OnSomeEvent;
        }
    }
}

This happens because events create strong references to their subscribers. If you forget to unsubscribe, your subscriber objects can’t be garbage collected, even when they’re no longer needed.

Here’s how to avoid these leaks:

Remember to unsubscribe when your object is done. If you’re using a framework like WPF or Xamarin, look for Unloaded or Disposed events to clean up.
Look into weak event patterns when you have long-lived publishers and shorter-lived subscribers.
Be careful with lambdas and anonymous methods as event handlers. They can capture variables from their surrounding scope and keep entire objects alive unintentionally.

Thread Safety

Another common issue comes up in multi-threaded applications. Both delegates and events can cause subtle bugs if you’re not careful:

// Thread safety issue with a multicast delegate
public class ThreadSafetyIssue
{
    private Action _callbacks;

    // This isn't thread-safe!
    public void AddCallback(Action callback)
    {
        _callbacks += callback;
    }

    public void RemoveCallback(Action callback)
    {
        _callbacks -= callback;
    }

    public void Execute()
    {
        _callbacks?.Invoke();
    }
}

The problem is that the += and -= operations on delegates aren’t atomic. If two threads try to add or remove handlers simultaneously, you might end up with unexpected results.

Here are two simple fixes:

Add proper synchronization using locks when adding or removing handlers.
Make a local copy of the delegate before invoking it to avoid race conditions:

public void Execute()
{
    // Capture the reference to prevent it changing during execution
    var callbacks = _callbacks;
    callbacks?.Invoke();
}

Conclusion

So which should you use, delegates or events? As with many things in programming, it depends on your specific needs:

Delegates give you flexibility. They’re your go-to tool when you need to pass behavior as data, implement callbacks, or create strategy patterns. They shine when you need return values or when the caller should control exactly when the callback happens.
Events provide structure and safety. They’re perfect for notification systems where you want to clearly separate publisher from subscriber, control who can trigger notifications, and allow multiple subscribers to listen without knowing about each other.

In real-world applications, I often find myself using both. For example, I might use delegates to implement customizable components of a system, while using events to notify the rest of the application when important milestones occur.

The key is understanding the strengths and appropriate uses of each. With delegates and events in your toolbox, you can create C# applications that are more flexible, maintainable, and robust. They’re both powerful features that, when used correctly, can dramatically improve your code quality and system architecture.

Introduction to Delegates and Events#

What Are Delegates?#

How Delegates Work#

Built-in Delegate Types#

Multicast Delegates#

What Are Events?#

Understanding Events#

Standard Event Pattern#

Key Differences Between Delegates and Events#

1. Access Control#

2. Intended Purpose#

3. Invocation Control#

4. Method Assignment#

When to Use Delegates vs Events#

Use Delegates When:#

Use Events When:#

Practical Example: Building a Notification System#

The Delegate Approach: Message Processors#

The Event Approach: Notification System#

Combining Both Approaches#

Best Practices#

For Delegates:#

For Events:#

Common Pitfalls and Solutions#

Memory Leaks#

Thread Safety#

Conclusion#