Явное событие добавить / удалить, неправильно понял?

Question

В последнее время я много смотрел на управление памятью и смотрел, как управляют событиями, теперь я вижу явный синтаксис добавления / удаления для подписки на события.

Я думаю, что это довольно просто, добавить / удалить просто позволяет мне выполнять другую логику, когда я подписываюсь и отписываюсь?Я получаю это, или есть что-то еще?

Кроме того, пока я здесь, любые советы / лучшие практики для очистки моих дескрипторов событий.

Answer 1

Свойства добавления / удаления в основном имеют ту же логику использования свойств set / get с другими членами. Он позволяет вам создавать дополнительную логику при регистрации события и инкапсулирует само событие.

Хороший пример того, ПОЧЕМУ вы хотите это сделать, - остановить дополнительные вычисления, когда они не нужны (никто не слушает событие).

Например, предположим, что события запускаются таймером, и мы не хотим, чтобы таймер работал, если никто не зарегистрирован на событие:

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();
   }
}

Возможно, вы захотите заблокировать добавление / удаление с помощью объекта (запоздалая мысль) ...

Answer 2

Да, синтаксис добавления / удаления позволяет вам реализовать собственную логику подписки.Когда вы их опускаете (стандартная запись для события), компилятор генерирует стандартные реализации.Это похоже на авто-свойства.

В следующем примере нет реальной разницы между Event1 и Event2.

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

  public event EventHandler Event2;  
}

Но это отдельная тема из «очистки» обработчиков,Это класс подписки, который должен отписаться.Класс публикации не может помочь в этом.
Представьте себе класс, который «очистил бы» список подписок своих событий.Он может сделать это разумно только тогда, когда сам будет утилизирован, и тогда он вряд ли будет продуктивным, так как класс Disposed обычно становится доступным вскоре после его утилизации.

Answer 3

Синтаксис добавления / удаления обычно используется для «пересылки» реализации события в другой класс.

Очистка подписок (не «дескрипторов событий») лучше всего выполнить с помощью IDisposable.

ОБНОВЛЕНИЕ: Существует несколько вариантов того, какой объект должен реализовывать IDisposable. Команда Rx приняла лучшее решение с точки зрения дизайна: сами подписки IDisposable. Обычные события .NET не имеют объекта, представляющего подписку, поэтому выбор между издателем (классом, для которого определяется событие) и подписчиком (обычно это класс, который содержит функцию-член, на которую подписывается). В то время как мои инстинкты проектирования предпочитают делать подписчика IDisposable, большая часть реального кода делает издателя IDisposable: это более простая реализация, и могут быть случаи, когда фактического экземпляра подписчика не существует.

(То есть, если код вообще очищает подписки на события. Большинство кодов этого не делает.)