我的很多课程都重复以下代码以实现IDisposable.这似乎违反了DRY(请勿重复自己)原则.我可以通过创建AbstractDisposable基类来避免一些工作,但是这似乎不合适/如果我需要扩展其他现有对象(假设那些对象本身不是一次性的)是行不通的.

另一个选择是使用模板/元语言,我可以为每个类指定托管和非托管资源的列表,并在构建项目时自动生成通用的Dispose Pattern-但到目前为止,我还没有使用元语言/对于这种常见情况,这似乎是极端的.

public class SomeDisposableClass : IDisposable
{
    IDisposable _something; //a managed resource (unique to this class / here for illustration)

    /* ... loads of code unique to this class ... */

    #region Dispose Pattern
    private bool _disposed = false;

    ~SomeDisposableClass()
    {
        Dispose(false);
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        // Check to see if Dispose has already been called. 
        if (!this._disposed)
        {
            if (disposing)
            {
                // Dispose managed resources.
                if (this._something!=null) this._something.Dispose(); //(unique to this class / here for illustration)
            }
            // Clean up any unmanaged resources
            this._disposed = true;
        }
    }
    #endregion
}

在不违反DRY原理的情况下,有没有很好的方法来实现合适的Dispose模式？

解决方法:

我尽力避免IDisposable.问题是它散布在整个代码库中.如果一个班级有一个可抛弃的成员,那么该班级也需要实现IDisposable等.

此外,当我们谈论类型层次结构时,IDisposable存在问题.
常见的情况是,如果您认为派生类需要释放资源,则将IDisposable粘贴到基类甚至接口上.但是,在大多数情况下,这仅是一个假设,并且是否需要清理资源实际上取决于实际的实现,这使接口成为一个泄漏的抽象.
如果类确实需要该接口,最好只实现该接口.
但这有其自身的问题：
某个接口的使用者应该如何知道他得到的具体实例(例如作为构造函数参数)需要处理？他将必须明确检查它.从根本上说,他将必须为他处理的每种非密封类型的每个实例执行此操作.

这些只是两个示例,它们表明您最好以某种方式设计类,从而使它们不需要实现IDisposable.

但是,如果确实需要实现此接口,则应遵循this CodeProject article描述的“一次性设计模式”.

它基本上将您的类型分为两个级别：

> 0级：0级的类仅包含非托管资源,不包含托管资源.这些类需要大多数通常的默认IDisposable模式,尽管您不必实现处理托管资源的部分.
>级别1：级别1的类仅包含级别0和1的托管资源.这些类仅需要IDisposable的简化实现,因为它们不包含非托管资源.该实现基本上只是在其0级和1级成员及其基类上调用Dispose.