2

Microsoft から提案された破棄パターンは、Dispose() とファイナライザーの両方が仮想の 3 番目のメソッド Dispose(bool) を呼び出す必要があることを示しています。したがって、次のようになります。

public class DisposeBase : IDisposable
{
    private bool _Disposed = false;

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

    ~DisposeBase()
    {
        Dispose(false);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!_Disposed)
        {
            if (disposing)
            {
                /* Get rid of managed resources */
            }

            /* Get rid of unmanaged resources */

            _Disposed = true;
        }
    }
}

派生クラスは Dispose(bool) をオーバーライドします。私はそれを次のように少し再構築することを考えました:

public abstract class ExtendableResourceHandlerBase : IDisposable
{
    private bool _Disposed = false;

    /* private resources managed and unmanaged */

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

    ~DisposeBase()
    {
        Dispose(false);
    }

    private void Dispose(bool disposing)
    {
        if (!_Disposed)
        {
            if (disposing)
            {
                ManagedDispose();

                // Dispose of own managed resources
            }

            UnmanagedDispose();

            // Dispose of own unmanged resources

            _Disposed = true;
        }
    }

    protected abstract void ManagedDispose();

    protected abstract void UnmanagedDispose();

    protected abstract xxx ExtendMe(....)

    // other member functionality
}

フレームワークで、インターフェイスを提供する抽象基本クラスと、破棄する必要があるリソースを取得するいくつかの実装を宣言するシナリオを考えています-したがって、IDisposableインターフェイスです。現在、この基本クラスを拡張するクライアントは、マネージド リソースとアンマネージド リソースの処分についても考慮する必要があります。マイクロソフトから提案されたパターンの場合、忘れてしまうかもしれません。ExtendableResourceHandlerBase名前は単なるプレースホルダーと考えてください。

私の意見では、これにより、DisposeBase から派生したクライアントが dispose メソッドを実装しやすくなります。また、別の質問の回答が示すように、他の人もそう考えています。マイクロソフトの優れた人々が現在のパターンを構築する理由として私が思いつく唯一の理由は、マネージド リソースとアンマネージド リソースの処分を分割するためではありません。それ以外の理由はありますか?教えてくれてどうもありがとう。

4

1 に答える 1