---
title: "Delegates & Events - A short Q&A"
url: "https://osherove.com/blog/2004/3/27/delegates-amp-events-a-short-qampa.md"
canonical: "https://osherove.com/blog/2004/3/27/delegates-amp-events-a-short-qampa.html"
published: "2004-03-27T19:43:00"
updated: "2004-03-27T19:43:00"
tags: [".Net Original"]
author: "Roy Osherove"
description: "The other day I gave a presentation about Delegates & events to folks who were new to C#. I dawned on me that in fact, this subject is kind of confusing, and several questions arose from this presentation. Disclaimer :…"
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Delegates & Events - A short Q&A

By Roy Osherove March 27, 2004 In [.Net Original](https://osherove.com/blog/category/net-original)

**Historical article** · Originally published March 27, 2004; technical details may be outdated.

The other day I gave a presentation about Delegates & events to folks who were new to C#. I dawned on me that in fact, this subject is kind of confusing, and several questions arose from this presentation.

**Disclaimer**: this is intended to be read by people already familiar with the Delegates and Events syntax, and is mostly related to C# syntax, since VB.Net syntax is a little different (simpler) in some cases.

**Q:  What’s the difference between a Delegate and a MultiCastDelegate?**

A: There is no real difference. Every delegate is a MultiCastDelegate, but in order to be logically called a MultiCastDelegate, it has to have more than one target in its Invocation list (multiple targets==multiple cast).

So, in essence, once you have created a delegate, you've created a MultiCastDelegate with an invocation list count of 1.

**Q: What’s the difference between a delegate and an event?**

A: I’ll divide the answer into 2 parts.

**Syntax wise:**

Here’s how one could define a delegate in a class:

public class **Class1**

{

public delegate void DomSomethingDelegate(int num1,int num2);

public DomSomethingDelegate MyDeleageteCallback;

}

And here’s how I would declare an event of this delegate:

public class **Class2**

{

public delegate void DomSomethingDelegate(int num1,int num2);

public **event** DomSomethingDelegate MyDeleageteCallback;

}

Notice that syntactically, the only difference is that I place an “event” keyword before the delegate variable declaration. That’s it.

**So what’s the “event” keyword adding to this?**

Well, to understand this, consider **Class1** in the code above. If I was using this class, as a client I could set it’s delegate variable like this:

Class1 c = new Class1();

c.MyDeleageteCallback+=new

Class1.DomSomethingDelegate(this.Calculate);

This simple code **adds** a new target to the delegate’s invocation list, which is perfectly fine. In fact, this same code will word with **Class2**. no difference what so ever so far. But consider this code which, instead of **adding** a new target to the delegate’s Invocation list, simply **sets the delegate** to a new delegate:

Class1 c = new Class1();

c.MyDeleageteCallback\=new

Class1.DomSomethingDelegate(this.Calculate);

This piece of code will work just fine with **class1**, but if we were to try to use it on **class2**, where there is the event keyword declared, we would get a compilation error.

In essence, declaring the event keyword prevents any of the delegate’s users from setting it to null. Why is this important? Image that as a client I would add to the delegates invocation list a callback to one of my class’s functions. So would other clients. All is well and good. Now imagine that someone, instead of using the “+=”, is simply setting the delegate to a new callback by using simply “=”. They basically just threw the old delegate and its invocation list down the drain and created a whole new delegate with a single item in its invocation list. All the other clients will not receive their callbacks when the time comes. It is this kind of situation that having the  “event” keyword is aiming to solve.

**In conclusion**: an _**event**_ declaration adds a layer of protection on the delegate instance. This protection prevents clients of the delegate from resetting the delegate and its invocation list, and only allows adding or removing targets from the invocation list.

## More in .Net Original

[All posts in .Net Original](https://osherove.com/blog/category/net-original)

- Mar 27, 2004

    ### [Israel .Net Architects user group meeting today :Service Oriented Architecture](https://osherove.com/blog/2004/3/27/israel-net-architects-user-group-meeting-today-service-orien.html)

- Mar 27, 2004

    ### [The problem with Multi-Cast Delegates](https://osherove.com/blog/2004/3/27/the-problem-with-multi-cast-delegates.html)

- Mar 24, 2004

    ### [The Regulator moves to SourceForge, slowly but surely](https://osherove.com/blog/2004/3/24/the-regulator-moves-to-sourceforge-slowly-but-surely.html)

- Mar 24, 2004

    ### [How CodeRush pissed me off](https://osherove.com/blog/2004/3/24/how-coderush-pissed-me-off.html)


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/