Использование IDisposable для отмены подписки на события

Да, дерзай. Хотя некоторые люди думают, что IDisposable реализован только для неуправляемых ресурсов, это не так - неуправляемые ресурсы оказываются самым большим преимуществом и наиболее очевидной причиной для его реализации. Я думаю, он приобрел эту идею, потому что люди не могли придумать никакой другой причины для ее использования. Это не похоже на финализатор, который является проблемой производительности, и GC нелегко справиться с этим.

Поместите любой код очистки в свой метод удаления. Это будет яснее, чище и с большей вероятностью предотвратит утечку памяти, и чертовски легче использовать правильно, чем пытаться не забыть удалить свои ссылки.

Цель IDisposable - улучшить работу вашего кода без необходимости выполнять много ручной работы. Используйте его силу в свою пользу и избавьтесь от какой-то искусственной ерунды о «замысле дизайна».

Я помню, что было достаточно сложно убедить Microsoft в полезности детерминированной доработки, когда впервые появилась .NET - мы выиграли битву и убедили их добавить его (даже если это был только шаблон проектирования в то время), используйте его!

Я бы лично проголосовал за метод Unsubscribe, чтобы удалить класс из событий. IDisposable - это шаблон, предназначенный для детерминированного высвобождения неуправляемых ресурсов. В этом случае вы не управляете никакими неуправляемыми ресурсами и, следовательно, не должны внедрять IDisposable.

IDisposable можно использовать для управления подписками на события, но, вероятно, не следует. В качестве примера указываю на WPF. Это библиотека, изобилующая событиями и обработчиками событий. Однако практически ни один класс в WPF не реализует IDisposable. Я бы воспринял это как указание на то, что событиями нужно управлять по-другому.

Одна вещь, которая беспокоит меня при использовании шаблона IDisposable для отказа от подписки на события, - это проблема финализации.

Dispose() функция в IDisposable должна вызываться разработчиком, ОДНАКО, если она не вызывается разработчиком, подразумевается, что GC вызовет эту функцию (по крайней мере, по стандартному шаблону IDisposable). Однако в вашем случае, если вы не вызываете Dispose, никто другой не будет - событие остается, и сильная ссылка удерживает GC от вызова финализатора.

Самого факта, что Dispose () не будет автоматически вызываться GC, мне кажется достаточно, чтобы не использовать IDisposable в этом случае. Возможно, он требует нового интерфейса для конкретного приложения, в котором говорится, что этот тип объекта должен иметь функцию Очистка, вызываемую для удаления с помощью GC.

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

public class DisposableEvent<T> : IDisposable
    {

        EventHandler<EventArgs<T>> Target { get; set; }
        public T Args { get; set; }
        bool fired = false;

        public DisposableEvent(EventHandler<EventArgs<T>> target)
        {
            Target = target;
            Target += new EventHandler<EventArgs<T>>(subscriber);
        }

        public bool Wait(int howLongSeconds)
        {
            DateTime start = DateTime.Now;
            while (!fired && (DateTime.Now - start).TotalSeconds < howLongSeconds)
            {
                Thread.Sleep(100);
            }
            return fired;
        }

        void subscriber(object sender, EventArgs<T> e)
        {
            Args = e.Value;
            fired = true;
        }

        public void Dispose()
        {
            Target -= subscriber;
            Target = null;
        }

    }

который позволяет вам написать этот код:

Class1 class1 = new Class1();
            using (var x = new DisposableEvent<object>(class1.Test))
            {
                if (x.Wait(30))
                {
                    var result = x.Args;
                }
            }

Один из побочных эффектов: вы не должны использовать ключевое слово event для своих событий, поскольку это предотвращает передачу их в качестве параметра во вспомогательный конструктор, однако, похоже, это не имеет каких-либо негативных последствий.

Другой вариант - использовать слабые делегаты или что-то в этом роде. например, слабые события WPF вместо необходимости явного отказа от подписки.

P.S. [OT] Я считаю решение предоставить только сильных делегатов единственной самой дорогостоящей ошибкой проектирования платформы .NET.

Из всего, что я читал об одноразовых расходных материалах, я бы сказал, что они были в основном изобретены для решения одной проблемы: своевременного освобождения неуправляемых системных ресурсов. Но все же все примеры, которые я нашел, не только сосредоточены на теме неуправляемых ресурсов, но также имеют еще одно общее свойство: Dispose вызывается только для ускорения процесса, который в противном случае произошел бы позже автоматически (GC -> finalizer -> dispose)

Однако вызов метода удаления, который отменяет подписку на событие, никогда не произойдет автоматически, даже если вы добавите финализатор, который вызовет ваше удаление. (по крайней мере, до тех пор, пока существует объект-владелец события - и если бы он был вызван, вы не получили бы выгоды от отмены подписки, поскольку объект-владелец события также исчезнет)

Итак, основное отличие состоит в том, что события каким-то образом создают граф объектов, который невозможно собрать, поскольку объект обработки событий внезапно становится ссылкой службы, на которую вы просто хотели ссылаться / использовать. Вы внезапно вынуждены вызвать Dispose - автоматическое удаление невозможно. Таким образом, Dispose получит другое тонкое значение, отличное от того, которое можно найти во всех примерах, где вызов Dispose - в грязной теории;) - не является необходимым, поскольку он будет вызываться автоматически (в какой-то момент) ...

В любом случае. Поскольку одноразовый шаблон уже является довольно сложным (имеет дело с финализаторами, которые трудно понять, и множеством руководств / контрактов) и, что более важно, в большинстве пунктов не имеет ничего общего с темой обратных ссылок на события, я бы сказал, что это будет легче отделить это в наших головах, просто не используя эту метафору для чего-то, что можно было бы назвать «извлечение корня из графа объектов» / «стоп» / «выключение».

Чего мы хотим достичь, так это отключить / остановить какое-то поведение (отказавшись от подписки на событие). Было бы неплохо иметь стандартный интерфейс, такой как IStoppable, с методом Stop (), который по контракту просто ориентирован на

• отключение объекта (+ всех его собственных остановок) от событий любых объектов, которые он не создал сам
• так что он больше не будет вызываться в стиле неявного события (поэтому может восприниматься как остановленный)
• могут быть собраны, как только любые традиционные ссылки на этот объект исчезнут

Назовем единственный интерфейсный метод, который выполняет отписку «Stop ()». Вы бы знали, что остановленный объект находится в приемлемом состоянии, но только остановлен. Может быть, было бы неплохо иметь простое свойство «Остановлен».

Было бы даже разумно иметь интерфейс «IRestartable», который наследуется от IStoppable и дополнительно имеет метод «Restart ()», если вы просто хотите приостановить определенное поведение, которое, безусловно, понадобится снова в будущем, или сохранить удаленный объект модели в истории для последующего отмены восстановления.

После всего написания я должен признаться, что только что видел пример IDisposable где-то здесь: http://msdn.microsoft.com/en-us/library/dd783449%28v=VS.100%29.aspx Но в любом случае, пока я не получу все детали и исходную мотивацию из IObservable я бы сказал, что это не лучший пример использования

• так как это опять же довольно сложная система, и здесь у нас есть только небольшая проблема
• и может быть, что одна из мотиваций этой новой системы состоит в том, чтобы в первую очередь избавиться от событий, что приведет к своего рода переполнению стека, касающемуся исходного вопроса.

Но, похоже, они на правильном пути. В любом случае: они должны были использовать мой интерфейс "IStoppable";), так как я твердо уверен, что есть разница в

• Dispose: «вы должны вызвать этот метод, иначе что-то может протечь , если сборщик мусора опаздывает» ....

а также

• Стоп: «вы должны вызвать этот метод, чтобы остановить определенное поведение»