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

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.)

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.