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