Явное Событие, add/remove, неправильно понятое?
Я изучал управление памятью много недавно и смотрел на то, как событиями управляют, теперь, я вижу, что явное добавляет/удаляет синтаксис для подписки события.
Я думаю, что это довольно просто, добавьте/удалите, просто позволяет мне выполнять другую логику, когда я подписываюсь и отказываюсь от подписки? Я получаю его или там больше к нему?
Кроме того, в то время как я здесь, любой совет / лучшие практики для чистки моих дескрипторов события.
2 ответа
Синтаксис добавления / удаления обычно используется для «пересылки» реализации события другому классу.
Очистку подписок (не «дескрипторов событий») лучше всего выполнять путем реализации IDisposable .
ОБНОВЛЕНИЕ: Существует несколько вариантов того, какой объект должен реализовывать IDisposable . Команда Rx приняла лучшее решение с точки зрения дизайна: сами подписки IDisposable . Обычные события .NET не имеют объекта, представляющего подписку, поэтому выбор остается между издателем (классом, в котором определено событие) и подписчиком (обычно класс, содержащий функцию-член, на которую подписывается). В то время как мои дизайнерские инстинкты предпочитают делать подписчика IDisposable , большая часть реального кода делает издателя IDisposable : это более простая реализация, и могут быть случаи, когда фактического подписчика нет пример.
(То есть, если код вообще очищает подписки на события. Большинство кода этого не делают.)
Да, синтаксис добавления / удаления позволяет реализовать собственную логику подписки. Когда вы их опускаете (стандартное обозначение события), компилятор генерирует стандартные реализации. Это похоже на автоматические свойства.
В следующем примере нет реальной разницы между Event1 и Event2.
public class Foo
{
private EventHandler handler;
public event EventHandler Event1
{
add { handler += value; }
remove { handler -= value; }
}
public event EventHandler Event2;
}
Но это отдельная тема от обработчиков «очистки». Отказ от подписки должен выполнять подписывающий класс. Издательский класс не может в этом сильно помочь.
Представьте себе класс, который «очищает» список подписки от своих событий. Он может сделать это разумно только тогда, когда он сам удален, и тогда он вряд ли будет продуктивным, поскольку класс Disposed обычно становится собираемым вскоре после его удаления.