Comments on: Intercepting Add and Remove of C# Event Delegates

By: Brij Sharma

Brij Sharma — Sat, 26 Nov 2011 17:37:47 +0000

I always use += and -= to manage adding and removing event handlers.
To explicitly do it in your code is something which I don’t think is required but like in the topic above is good to show off.

By: Hi Vis Jacket

Hi Vis Jacket — Tue, 11 Jan 2011 14:05:50 +0000

A lot of good feedback on this article, thanks to everyone for sharing. Just like most things with Windows, there is more than 1 way to do things. More than 1 way to skin a cat, I suppose. ;D

I don’t have the need to dig further under the hood, so the += and -= operators work just fine for our every day applications, but it’s nice to know we can expand on that if needed.

By: Zachary

Zachary — Fri, 03 Sep 2010 16:52:29 +0000

Echoing what Hank Hatch says below, using this direct wrap function enables you to wrap built in .NET classes like BackgroundWorker and abstract an Interface for testing purposes (ie generating mocks etc) and using the Decorator Pattern (ref Head First Design Patterns).

Hank Hatch Says:

November 3rd, 2008 at 11:46 am
Also it is more of a direct wrap to do it like this ->

private StateMachineEventHandler canTransition;
public event StateMachineEventHandler CanTranistion
{
add { this.canTransition += value; }
remove { this.canTransition -= value; }
}

which is pretty darn simple considering the power it can give you.

By: Levi

Levi — Thu, 26 Feb 2009 06:08:30 +0000

Actually, the most common reason to implement an add & remove on an event is for memory consumption. For instance, let’s say you have a type which has a large number of events. If those events are defined with just a public event field, then the type has to allocate store for each delegate, even if no one is subscribed to the event.
For instance, if the type has 15 events, then when you create an instance of the object, it will have 15 pointers to delegates. Most of the events will be null.
Now, if we change the type to use add and remove and implement the add and remove like so:
public EventHandler Click
{
add
{
eventList.Add(ClickKey, value);
}
remove
{
eventList.Remove(ClickKey, value);
}
}

Where eventList is an EventHandlerList, then your type only needs one reference to track all of it’s events instead of 15. If an event is never subscribed to, then it creates no overhead. While the field approach would always require a null pointer.

Btw, add and remove aren’t the only accessors supported by the .net framework. C++ allows you to also define the raise accessor, but it’s not allowed in C#.

By: jgr4

jgr4 — Thu, 15 Jan 2009 22:23:03 +0000

Thanks for the post. One usage is for debugging. I couldn’t figure out where handlers were getting added and why there seemed to be to many. This technique allows you to put a breakpoint or a Debug.WriteLine in the add {}.

By: Cosmin Onea

Cosmin Onea — Thu, 11 Dec 2008 00:29:20 +0000

http://www.cosminonea.net/2008/12/10/Subsonic30AndAPossibleSerializationProblem.aspx

This may be one possible good usage.

By: Hank Hatch

Hank Hatch — Mon, 03 Nov 2008 17:46:03 +0000

Also it is more of a direct wrap to do it like this ->

private StateMachineEventHandler canTransition;
public event StateMachineEventHandler CanTranistion
{
add { this.canTransition += value; }
remove { this.canTransition -= value; }
}

which is pretty darn simple considering the power it can give you.

By: Hank Hatch

Hank Hatch — Mon, 03 Nov 2008 17:34:51 +0000

The main purpose of this is really the following:
In C++ we basically had to manage our own lists of function pointers (callbacks) in order to provide for notifications.
In visual basic we had events built in.
So in order to make events easier and more modern and acceptable (probably to convert more VB programmers into C# programmers) events had to be a language feature.
Type safe function pointers (delegates) are used to make this possible.
Built into delegates have invokation lists.
Enter managed code and garbage collection.
Enter you as a component developer.
If you do not declare your delegate as a private member of your class then YOU cannot access it’s invokation list.
If you only declare the event public (and therefore do not have a property) then you are limited by the compiler to the access of that field.
The documentation states that the keyword event limits access to the delegate to using the binary += and -+ operators.
So long story short is this.
Considering the keyword “event” exists is NO excuse to be irrisponsible in coding and lazy.
Not using this pattern is somewhat the same as being irrisponsible with your pointers in a non managed environment.
It is similar to NOT calling delete or not creating a “smart pointer” type situation where you bind delete, removing of a reference counter, and the setting to null all in one step.
What I am saying is this.
If you are going to code a component that offers many events and design that component so that it is going to be heavily used then you don’t want to subject every single one of you clients to surviving generation 1 garbage collection.
If you offer an event and you have subscribers even if this goes out of scope your hidden non accessible invokation lists all still have references to you old clients. They will then NOT be released from garbage collection as soon as they could be. If you combine structures like this in algorithms that utilize a high number of objects or lots of stack space then you are coding yourself into the situation that you do not have the EXPLICIT unbinding of objects in object graphs so that your component can be used in many situations.

Basically this is another way to say it. If your component offers events it is better to also offer IDisposable so that the client code can decide how things are handled. Create a private delegate. Create a public event so clients can subscribe to the notification with the += and -+ operators they are used to. But now VERY important -> in your Dispose enumerate the private delegates invokation list and remove the references to the clients. This is a “TearDown” and the same thing WAS necessary in VB 6 for certain situations (pointers to parent objects in collections as an example with a COM reference counting systems).

This way you can better control and increase the number of objects that will be freed during a lower generation of garbage collection.

Remember just because it is C# and managed code DOES NOT mean you cannot have a memory leak. If you want to expand an object oriented language with “out-going calls” or “events” which is basically implemented with circular referencing then be aware that just because something was automated for you DOES NOT mean you can’t get in trouble.

Keep the private delegate for anytime you feel you need to control the members of the invokation list. I have been stressing just the garbage collection and memory leak but there are other patterns. Use it when you want to dump the list and require new subscriptions from within a server or singleton periodically. Often templating out this pattern without the dispose is my preference NOT because I want to show people what I know but because I want to somewhat document that depending on how my object is used a refactor should take place which includes some code in here. That is not obvious with the use of the public event field.