这是“传统”技术的合法替代方案吗？处理类层次结构的模式？

Question

我不喜欢样板代码：复制粘贴重用可能容易出错。即使您使用代码片段或智能模板，也不能保证其他开发人员会这样做，这意味着不能保证他们做得正确。而且，如果您必须查看代码，则必须理解它和/或维护它。

我想从社区知道的是：我对类层次结构的 IDispose 实现是否是 "传统"处置模式？我所说的合法​​是指正确、性能相当良好、健壮且可维护。

我可以接受这个替代方案是完全错误的，但如果是这样，我想知道为什么。

此实现假设您对类层次结构有完全控制权；如果不这样做，您可能不得不求助于样板代码。对 Add*() 的调用通常在构造函数中进行。

public abstract class DisposableObject : IDisposable
{
  protected DisposableObject()
  {}

  protected DisposableObject(Action managedDisposer)
  {
     AddDisposers(managedDisposer, null);
  }

  protected DisposableObject(Action managedDisposer, Action unmanagedDisposer)
  {
     AddDisposers(managedDisposer, unmanagedDisposer);
  }

  public bool IsDisposed
  {
     get { return disposeIndex == -1; }
  }

  public void CheckDisposed()
  {
     if (IsDisposed)
        throw new ObjectDisposedException("This instance is disposed.");
  }

  protected void AddDisposers(Action managedDisposer, Action unmanagedDisposer)
  {
     managedDisposers.Add(managedDisposer);
     unmanagedDisposers.Add(unmanagedDisposer);
     disposeIndex++;
  }

  protected void AddManagedDisposer(Action managedDisposer)
  {
     AddDisposers(managedDisposer, null);
  }

  protected void AddUnmanagedDisposer(Action unmanagedDisposer)
  {
     AddDisposers(null, unmanagedDisposer);
  }

  public void Dispose()
  {
     if (disposeIndex != -1)
     {
        Dispose(true);
        GC.SuppressFinalize(this);
     }
  }

  ~DisposableObject()
  {
     if (disposeIndex != -1)
        Dispose(false);
  }

  private void Dispose(bool disposing)
  {
     for (; disposeIndex != -1; --disposeIndex)
     {
        if (disposing)
           if (managedDisposers[disposeIndex] != null)
              managedDisposers[disposeIndex]();
        if (unmanagedDisposers[disposeIndex] != null)
           unmanagedDisposers[disposeIndex]();
     }
  }

  private readonly IList<Action> managedDisposers = new List<Action>();
  private readonly IList<Action> unmanagedDisposers = new List<Action>();
  private int disposeIndex = -1;
}

从某种意义上说，这是一个“完整”的实现，我提供了对终结器的支持（知道大多数实现不需要终结器），检查对象是否已释放等。例如，真正的实现可能会删除终结器，或者创建一个包含终结器的 DisposableObject 子类。基本上，为了这个问题，我把我能想到的一切都投入了。

我可能错过了一些边缘情况和深奥的情况，因此我邀请任何人在这种方法中找出漏洞或通过更正来支持它。

其他替代方案可能是使用单个队列。 DisposableObject 中的 disposers 而不是两个列表；在这种情况下，当调用处理程序时，它们将从列表中删除。我能想到的还有其他一些细微的变化，但它们具有相同的一般结果：没有样板代码。

Answer 1

您可能遇到的第一个问题是，C# 只允许您从单个基类继承，在本例中该基类始终为DisposableObject。在这里，您通过强制附加层使类层次结构变得混乱，以便需要从 DisposableObject 继承的类和其他一些对象可以这样做。

通过此实现，您还会引入许多开销和维护问题（更不用说每次新人加入该项目时的重复培训成本，并且您必须解释他们应该如何使用此实现而不是定义的模式） 。您知道需要跟踪两个列表的多个状态，对操作的调用没有错误处理，调用操作时的语法看起来“奇怪”（虽然从数组调用方法可能很常见，简单地将 () 放在数组访问后面的语法看起来很奇怪）。

我理解减少必须编写的样板文件数量的愿望，但可处置性通常不是我建议采取捷径或以其他方式偏离模式的领域之一。我通常得到的最接近的方法是使用辅助方法（或扩展方法）来包装对给定对象上的 Dispose() 的实际调用。这些调用通常看起来像：

if (someObject != null)
{
   someObject.Dispose();
}

这可以使用辅助方法来简化，但请记住，FxCop（或检查正确处置实现的任何其他静态分析工具）会抱怨。

就性能而言，请记住，您将使用这种类型的实现进行大量委托调用。从委托的性质来看，这比普通方法调用的成本要高一些。

可维护性在这里肯定是一个问题。正如我所提到的，每次新人加入项目时，您都会产生重复的培训成本，并且您必须解释他们应该如何使用此实现而不是定义的模式。不仅如此，您还会遇到每个人都记得将一次性物品添加到您的清单中的问题。

总的来说，我认为这样做是一个坏主意，会在以后引起很多问题，特别是随着项目和团队规模的增加。

Answer 2

我偶尔需要一次跟踪多个打开的文件或其他资源。当我这样做时，我使用类似于以下的实用程序类。然后该对象仍然按照您的建议实现 Displose()，即使跟踪多个列表（托管/非托管）对于开发人员来说也很容易且显而易见。此外，从 List 对象派生并非偶然，它允许您在需要时调用 Remove(obj)。我的构造函数通常如下所示：

        _resources = new DisposableList<IDisposable>();
        _file = _resources.BeginUsing(File.Open(...));

这是类：

    class DisposableList<T> : List<T>, IDisposable
        where T : IDisposable
    {
        public bool IsDisposed = false;
        public T BeginUsing(T item) { base.Add(item); return item; }
        public void Dispose()
        {
            for (int ix = this.Count - 1; ix >= 0; ix--)
            {
                try { this[ix].Dispose(); }
                catch (Exception e) { Logger.LogError(e); }
                this.RemoveAt(ix);
            }
            IsDisposed = true;
        }
    }

Answer 3

我喜欢 csharptest 答案中的一般模式。围绕处置设计一个基类有点限制，但是如果您使用 vb.net 或者不介意某些带有线程静态变量的游戏，那么专门设计的基类将可以注册变量以进行处置，甚至当它们在字段初始值设定项或派生类构造函数中创建时（通常，如果在字段初始值设定项中引发异常，则无法处置任何已分配的 IDisposable 字段，并且如果派生类的构造函数抛出异常，则会出现部分创建的基础对象无法自行处置）。

不过，我不会打扰您的非托管资源列表。具有终结器的类不应保留对终结不需要的任何对象的引用。相反，终结所需的内容应该放在它自己的类中，并且“主”类应该创建后一个类的实例并保留对它的引用。