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 subsc

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.

Answer 3

Add/remove syntax is commonly used to "forward" an event implementation to another class.

Cleaning up subscriptions (not "event handles") is best done by implementing IDisposable.

UPDATE: There is some variation on which object should implement IDisposable. The Rx team made the best decision from a design perspective: subscriptions themselves are IDisposable. Regular .NET events do not have an object that represents the subscription, so the choice is between the publisher (the class on which the event is defined) and the subscriber (usually the class that contains the member function being subscribed). While my design instincts prefer making the subscriber IDisposable, most real-world code makes the publisher IDisposable: it's an easier implementation, and there may be cases where there isn't an actual subscriber instance.

(That is, if the code actually cleans up event subscriptions at all. Most code does not.)