是否滥用 IDisposable 从被认为有害的“使用”语句中获益？ [关闭]

Question

接口IDisposable的目的是有序释放非托管资源。它与 using 关键字密切相关，该关键字定义了一个作用域，在该作用域结束后，相关资源将被处置。

因为这种机制非常简洁，我一再想让类实现IDisposable，以便能够以不适合的方式滥用这种机制。例如，可以实现类来处理这样的嵌套上下文：

class Context : IDisposable
{
    // Put a new context onto the stack
    public static void PushContext() { ... }

    // Remove the topmost context from the stack
    private static void PopContext() { ... }

    // Retrieve the topmost context
    public static Context CurrentContext { get { ... } }

    // Disposing of a context pops it from the stack
    public void Dispose()
    {
        PopContext();
    }
}

调用代码中的用法可能如下所示：

using (Context.PushContext())
{
   DoContextualStuff(Context.CurrentContext);
} // <-- the context is popped upon leaving the block

（请注意，这只是一个例子，并不是这个问题的主题。）

Dispose() 在离开 using 语句的作用域时被调用这一事实也可以被利用来实现各种依赖于作用域的东西，例如计时器。这也可以通过使用try ... finally 构造来处理，但在这种情况下，程序员将不得不手动调用某些方法（例如Context.Pop），而using 构造可以为thon 执行此操作。

IDisposable 的这种用法与 as stated in the documentation 的预期用途不一致，但诱惑仍然存在。

是否有具体的理由来说明这是一个坏主意并永远打消我的幻想，例如垃圾收集的复杂性、异常处理等。或者我应该继续以这种方式滥用这种语言概念来放纵自己吗？

Answer 1

所以在 asp.net MVC 视图中，我们看到以下构造：

using(Html.BeginForm())
{
    //some form elements
}

滥用？微软（间接）说不。

如果您的构造需要在完成后发生某些事情，IDisposable 通常可以很好地工作。我已经不止一次这样做了。

Answer 2

“这样使用是不是滥用IDisposable接口”？大概吧。

将using 用作纯粹的“范围”构造是否会使代码的意图更明显并具有更好的可读性？当然。

后者对我来说胜过前者，所以我说使用它。

Answer 3

您当然不会是第一个以这种方式“滥用” IDisposable 的人。正如StatsD.NET client 所展示的那样，我最喜欢的可能是在计时器中使用它：

using StatsdClient;
...
using (statsd.LogTiming( "site.db.fetchReport" ))
{
  // do some work
}
// At this point your latency has been sent to the server

事实上，我很确定微软自己在一些库中使用它。我的经验法则是 - 如果它提高了可读性，那就去吧。