Explicit Event add/remove, misunderstood?

Question

I've been looking into memory management a lot recently and have been looking at how events are managed, now, I'm seeing the explicit add/remove syntax for the event subscription.

I think it's pretty simple, add/remove just allows me to perform other logic when I subscribe and unsubscribe? Am I getting it, or is there more to it?

Also, while I'm here, any advice / best practices for cleaning up my event handles.

Answer 1

The add/remove properties are basically of the same logic of using set/get properties with other members. It allows you to create some extra logic while registering for an event, and encapsulates the event itself.

A good example for WHY you'd want to do it, is to stop extra computation when it's not needed (no one is listening to the event).

For example, lets say the events are triggered by a timer, and we don't want the timer to work if no-one is registered to the event:

private System.Windows.Forms.Timer timer = new System.Windows.Forms.Timer();
private EventHandler _explicitEvent;
public event EventHandler ExplicitEvent 
{
   add 
   { 
       if (_explicitEvent == null) timer.Start();
       _explicitEvent += value; 
   } 
   remove 
   { 
      _explicitEvent -= value; 
      if (_explicitEvent == null) timer.Stop();
   }
}

You'd probably want to lock the add/remove with an object (an afterthought)...

Answer 2

Yes, the add/remove syntax allows you to implement your own subscription logic. When you leave them out (the standard notation for an event) the compiler generates standard implementations. That is like the auto-properties.

In the following sample, there is no real difference between Event1 and Event2.

public class Foo  
{ 
  private EventHandler handler; 
  public event EventHandler Event1 
  { 
    add { handler += value; } 
    remove { handler -= value; } 
  } 

  public event EventHandler Event2;  
}

But this is a separate topic from 'cleaning up' handlers. It is the subscribing class that should do the unsubscribe. The publishing class can not help with this very much.
Imagine a class that would 'clean' up the subscription list of its events. It can only sensibly do this when it is Disposed itself, and then it is unlikely to be productive as a Disposed class usually becomes collectable shortly after it is Disposed.