使用 IDisposable 取消订阅事件

Question

我有一个处理来自 WinForms 控件的事件的类。 根据用户正在执行的操作，我引用该类的一个实例并创建一个新实例来处理同一事件。 我需要首先从事件中取消订阅旧实例 - 很简单。 如果可能的话，我想以非专有的方式执行此操作，这似乎是 IDisposable 的工作。 但是，大多数文档仅在使用非托管资源时建议使用 IDisposable，但这并不适用于此。

如果我实现 IDisposable 并在 Dispose() 中取消订阅事件，我是否会歪曲其意图？ 我应该提供一个 Unsubscribe() 函数并调用它吗？

---

编辑：这是一些虚拟代码，显示了我正在做的事情（使用 IDisposable）。 我的实际实现与一些专有数据绑定有关（长话短说）。

class EventListener : IDisposable
{
    private TextBox m_textBox;

    public EventListener(TextBox textBox)
    {
        m_textBox = textBox;
        textBox.TextChanged += new EventHandler(textBox_TextChanged);
    }

    void textBox_TextChanged(object sender, EventArgs e)
    {
        // do something
    }

    public void Dispose()
    {
        m_textBox.TextChanged -= new EventHandler(textBox_TextChanged);
    }
}

class MyClass
{
    EventListener m_eventListener = null;
    TextBox m_textBox = new TextBox();

    void SetEventListener()
    {
        if (m_eventListener != null) m_eventListener.Dispose();
        m_eventListener = new EventListener(m_textBox);
    }
}

在实际代码中，“EventListener”类涉及的比较多，并且每个实例都有唯一的意义。 我在集合中使用它们，并在用户单击时创建/销毁它们。

---

结论

我接受gbjbaanb的回答，位于至少现在是这样。 我认为使用熟悉的界面的好处超过了在不涉及非托管代码的情况下使用它的任何可能的缺点（该对象的用户如何知道这一点？）。

如果有人不同意 - 请发布/评论/编辑。 如果可以对 IDisposable 提出更好的论据，那么我将更改已接受的答案。

Answer 1

是的，去做吧。 尽管有些人认为 IDisposable 仅针对非托管资源实现，但事实并非如此 - 非托管资源恰好是最大的胜利，也是实现它的最明显的原因。 我认为它之所以获得这个想法是因为人们想不出任何其他理由来使用它。 它不像终结器，终结器是一个性能问题，而且 GC 不容易处理好。

将所有整理代码放入您的 dispose 方法中。 与试图记住撤消引用相比，它会更清晰、更干净，并且更容易防止内存泄漏，而且更容易正确使用。

IDisposable 的目的是让您的代码更好地工作，而无需您做大量的手动工作。 利用它的力量对你有利，克服一些人为的“设计意图”废话。

我记得当 .NET 首次问世时，说服 Microsoft 确定性终结的有用性是非常困难的 - 我们赢得了这场战斗并说服他们添加它（即使当时它只是一种设计模式），使用它！

Answer 2

我个人的投票是使用取消订阅方法，以便从事件中删除该类。 IDisposable 是一种用于确定性释放非托管资源的模式。 在这种情况下，您不管理任何非托管资源，因此不应实现 IDisposable。

IDisposable 可用于管理事件订阅，但可能不应该。 作为示例，我向您介绍 WPF。 这是一个充满事件和事件处理程序的库。 然而，WPF 中几乎没有类实现 IDisposable。 我认为这表明事件应该以另一种方式进行管理。

Answer 3

使用 IDisposable 模式取消订阅事件时困扰我的一件事是终结问题。

IDisposable 中的 Dispose() 函数应该由开发人员调用，但是，如果开发人员不调用它，则可以理解 GC 将调用这个函数（至少通过标准的 IDisposable 模式）。 但是，在您的情况下，如果您不调用 Dispose ，其他人不会调用 - 事件将保留，并且强引用会阻止 GC 调用终结器。

在我看来，GC 不会自动调用 Dispose() 的事实足以让我们在这种情况下不使用 IDisposable。 也许它需要一个新的应用程序特定接口，该接口表示这种类型的对象必须具有调用的Cleanup函数才能由GC处理。

Answer 4

另一种选择是使用 弱代表 或类似的东西WPF 弱事件，而不必显式取消订阅。

PS [OT] 我认为只提供强委托的决定是 .NET 平台最昂贵的设计错误。

Answer 5

我认为一次性是指 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 关键字，因为这会阻止将它们作为参数传递给辅助构造函数，但是，这似乎不会产生任何不良影响。

Answer 6

从我读到的有关一次性用品的所有内容来看，我认为它们实际上主要是为了解决一个问题而发明的：及时释放非托管系统资源。 但我发现的所有示例仍然不仅集中在非托管资源主题上，而且还有另一个共同属性：
调用 Dispose 只是为了加快进程，否则稍后会自动发生（GC -> 终结器 -> dispose）

调用取消订阅事件的 dispose 方法，但永远不会自动发生，即使您添加一个会调用您的 dispose 的终结器。 （至少只要事件拥有对象存在 - 并且如果它被调用，您将不会从取消订阅中受益，因为事件拥有对象无论如何也会消失）

所以主要区别是事件以某种方式构建一个对象无法收集的图，因为事件处理对象突然变成您只想引用/使用的服务的引用。 您突然被迫调用Dispose - 无法自动处置。 因此，Dispose 会得到一个微妙的其他含义，而不是在所有示例中发现的含义，在这些示例中，Dispose 调用（在肮脏的理论中；）- 是不必要的，因为它会被自动调用（在某些时候）......

无论如何。
由于一次性模式已经相当复杂（处理很难正确执行的终结器以及许多指南/合同），更重要的是在大多数情况下与事件反向引用主题无关，我想说它是只要不使用可以称为“从对象图中取消根”/“停止”/“关闭”的隐喻，就可以更容易地在我们的头脑中将其分开。

我们想要实现的是禁用/停止某些行为（通过取消订阅事件）。
最好有一个像 Istoppable 这样带有 Stop() 方法的标准接口，按照约定，它只专注于

• 让对象（+所有它自己的可停止对象）与任何不是它自己创建的对象的事件断开连接
• 这样它就不会再以隐式事件样式的方式被调用（因此可以被视为已停止），
• 一旦对该对象的任何传统引用消失，就可以收集它让

我们调用执行取消订阅的唯一接口方法“Stop()” ”。 您会知道停止的对象处于可接受的状态，但只是停止了。 也许一个简单的属性“Stopped”也是一个不错的选择。

如果您只是想暂停将来肯定会再次需要的某个行为，或者存储已删除的行为，那么拥有一个继承自 Istoppable 的接口“IRestartable”甚至还有一个方法“Restart()”也是有意义的。历史记录中的模型对象以供以后撤消恢复。

写完这篇文章后，我必须承认刚刚在这里看到了 IDisposable 的示例：http://msdn.microsoft.com/en-us/library/dd783449%28v=VS.100%29.aspx
但无论如何，在我了解 IObservable 的每个细节和最初动机之前，我会说这不是最好的用例示例，

• 因为它又是一个非常复杂的系统，我们在这里只有一个小问题
• ，它可能是其中之一整个新系统的动机是首先消除事件，这将导致与原始问题有关的某种堆栈溢出，

但看起来他们走在正确的轨道上。 无论如何：他们应该使用我的接口“IStoppable”；）因为我坚信 Dispose 存在差异

• ：“你应该调用该方法或可能泄漏 >如果 GC 发生晚了” ....

并

• 停止：“你必须调用此方法停止某种行为”

Answer 7

IDisposable 坚定地与资源有关，并且是足够多问题的根源，我认为不会让水进一步变得浑浊。

我也在您自己的界面上投票支持取消订阅方法。

Answer 8

一种选择可能是根本不取消订阅——只是改变订阅的含义。 如果事件处理程序可以足够智能，能够根据上下文知道它要做什么，那么您首先不需要取消订阅。

对于您的特定情况，这可能是也可能不是一个好主意 - 我认为我们没有真正获得足够的信息 - 但值得考虑。

Answer 9

不，您并没有阻止 IDisposable 的意图。 IDisposable 旨在作为一种通用方法，以确保当您使用完某个对象后，您可以主动清理与该对象相关的所有内容。 它不必只是非托管资源，还可以包括托管资源。 事件订阅只是另一种托管资源！

实践中经常出现的类似场景是，您将在您的类型上实现 IDisposable，纯粹是为了确保您可以在另一个托管对象上调用 Dispose()。 这也不是变态，这只是整洁的资源管理！