パターンを破棄

「誰もがそれをするか、何かがどこかに書かれているという理由だけで、いくつかのイディオムに従うべきではない



他の人のコードを読んでリファクタリングしている間の記事の著者の考え



.NETプラットフォームが自動メモリ管理をサポートしていることは周知の事実です。 つまり、 新しいキーワードを使用してオブジェクトを作成する場合、自分でオブジェクトを解放する必要はありません。 ガベージコレクターはオブジェクトの「到達可能性」を判断し、オブジェクトへのルートリンクがない場合は解放されます。 ただし、ソケット、アンマネージドメモリバッファー、オペレーティングシステム記述子などのリソースになるとすぐに、ガベージコレクターは全体的に手を洗い、そのようなリソースでの作業に関する全体的なスマットは開発者の肩に落ちます。



しかし、ファイナライザについてはどうですか？ -あなたが尋ねます。 そう、そうです、ファイナライザーは本当にリソースを解放するように設計されていますが、問題は呼び出しの時間が決定されていないことです。つまり、いつ呼び出されるか、または呼び出されるかどうかは誰にもわかりません。 また、ファイナライザを呼び出す順序は定義されていません。したがって、ファイナライザを呼び出すときに、オブジェクトの一部がすでに「破棄」されている可能性があります。 一般に、ファイナライザー-実際にはそうですが、これはより安全なロープのようなものであり、リソースを管理する通常の手段ではありません。

イディオムRAII

C ++では、スマートポインター以外に自動メモリ管理用の組み込みツールがないため、リソース（*）のタイムリーなリリースにパターン（またはイディオム）が積極的に使用されています。 このイディオムは「Resource Acquisition Is Initialization」（RAII）と呼ばれ、次のとおりです。 リソースはコンストラクターでキャプチャーされ、デストラクタで解放されます。デストラクタは自動的に呼び出されるため、リソースを管理するための追加の作業は必要ありません。



決定論的なリソース管理の同じ考え方が、 IDisposableインターフェイス（C＃）およびdisposeメソッド（Java）の形式で、.NETまたはJava（**）などの他の「スマート」および「管理」環境にも転送されることは驚くことではありません。 しかし、これらの環境は古いC ++よりもスマートであり、メモリ管理に関連する主な問題も解決されているため、このイディオムはあまりうまく動きませんでした。 いいえ、私を正しく理解し、非常にうまく移動しましたが、このためにusingブロック（C＃言語の場合）またはtry - with - resources ステートメント （Java 7の場合）を使用する必要があります。リソースのリリースの痕跡はありません。

// using

using ( FileStream file = File .OpenRead( "foo.txt" ))

{

//

if (someCondition) return ;

// using

}

// , - using?

FileStream file2 = File .OpenRead( "foo.txt" );



* This source code was highlighted with Source Code Highlighter .

ただし、これが.NETのリソースを操作するときに発生する唯一の問題ではありません。 すぐにわかるように、リソースを解放するために通常の方法を使用すると、いくつかの他の問題があります。 Disposeメソッドはリソースを解放するため、ファイナライザー呼び出しは不要になり、キャンセルする必要があります。さらに、 Disposeメソッドはクラス不変式を破棄します。これにより、ユーザーは破棄または部分的に破棄されたオブジェクトを取得できます。 また、これには、 Disposeメソッドとクラスのすべてのパブリックメソッドの両方で追加のチェックが必要です。



これはすべて、比較的単純なイディオムRAIIが.NETプラットフォーム上で「破棄パターン」と呼ばれるパターンに流出したという事実につながりました。 ただし、その検討に移る前に、.NETプラットフォームに存在する2種類のリソース（管理対象リソースと非管理対象リソース）を見てみましょう。

管理対象および管理対象外のリソース

.NETには、管理対象リソースと管理対象外リソースの2種類のリソースがあります。 そして、それらを区別することは非常に簡単です。アンマネージリソースには、 IntPtr 、生のソケット記述子などの「生の」リソースのみが含まれます。 RAIIイディオムを使用して、このリソースがコンストラクターで取得してDisposeメソッドで解放するオブジェクトにパッケージ化された場合、そのようなリソースは既に管理されています。 実際、マネージリソースはアンマネージリソースの「スマートシェル」であり、独創的な関数を呼び出す必要はなく、 IDisposableインターフェイスのDisposeメソッドを呼び出す必要があるリリースです。

class NativeResourceWrapper : IDisposable

{

// IntPtr –

private IntPtr nativeResourceHandle;

public NativeResourceWrapper()

{

// «»

nativeResourceHandle = AcquireNativeResource();

}

public void Dispose()

{

// , , -

//

ReleaseNativeResource(nativeResourceHandle);

}

// ,

~NativeResourceWrapper() {...}

}



* This source code was highlighted with Source Code Highlighter .

したがって、任意のオブジェクトは、2つのタイプのリソースを所有できます。アンマネージリソース（ IntPtrなど ）を直接含めるか、マネージリソース（ NativeResourceWrapperなど ）へのリンクを含めることができます。どちらの場合も、これらのリソースの1つを含むオブジェクトそれ自体が管理対象リソースになります。 これはあまり基本的ではないように思えるかもしれませんが、2つのタイプのリソースの違いを理解することは非常に重要です。

パターンを破棄

したがって、オブジェクトは2種類のリソースを管理できることがわかっています。 管理対象リソースと管理 対象外リソースです。 リソースを解放する2つの方法があるという事実だけでなく、 Disposeメソッドを使用する決定論的手法とファイナライザーを使用する非決定 論的手法（***）もあります。 さて、このすべての良いものと一緒に暮らす方法、そして最も重要なことには、この良いものを解放する方法を見てみましょう。



Disposeパターンのアイデアは次のとおりです。リソースを解放するロジック全体を別のメソッドに入れましょう。Disposeメソッドとファイナライザの両方から呼び出します。一方、このメソッドを呼び出したユーザーを知らせるフラグを追加します。 この単純なアイデアにはかなり多くの詳細が含まれているため、ポイントごとにDisposeパターンを提示しましょう。



1.マネージリソースまたはアンマネージリソースを含むクラスは、 IDisposableインターフェイスを実装します

class Boo : IDisposable { ... }



* This source code was highlighted with Source Code Highlighter .

2.クラスには、リソースを解放するすべての作業を行うDispose （ bool disposing ）メソッドが含まれています。 disposingパラメーターは、このメソッドがDisposeメソッドから呼び出されるか、ファイナライザーから呼び出されるかを示します。 このメソッドは、非密閉クラスの場合は 仮想で、密閉クラスの場合はプライベートで保護する必要があります

// -sealed

protected virtual void Dispose( bool disposing) {}



// sealed

private void Dispose( bool disposing) {}



* This source code was highlighted with Source Code Highlighter .

3. Disposeメソッドは常に次のように実装されます。まず、 Dispose （ true ）メソッドが呼び出され、次にGCメソッド呼び出しが続きます。 SuppressFinalize （） 、ファイナライザが呼び出されないようにします。

public void Dispose()

{

Dispose( true /*called by user directly*/ );

GC.SuppressFinalize( this );

}



* This source code was highlighted with Source Code Highlighter .

GCメソッド。 SuppressFinalize （）は、 Dispose （ true ）メソッドが例外で「落ちた」場合、ファイナライザがキャンセルされないため、まずDispose （ true ）を呼び出した後に呼び出す必要があります。 第二に、 GC 。 ファイナライザはその子孫に表示される可能性があるため、ファイナライザを含まないクラスでもSuppressFinalize （）を呼び出す必要があります（つまり、すべての非密閉クラスでGC。SuppressFinalize （）メソッドを呼び出す必要があります）。



4. Dispose （ bool disposing ） メソッドには2つの部分が含まれます。（1）このメソッドがDisposeメソッドから呼び出される場合（つまり、 disposingパラメーターがtrueの場合 ）、マネージリソースとアンマネージリソースを解放し、（2）メソッドがファイナライザから呼び出される場合ガベージコレクション（ disposingパラメーターがfalse ）、アンマネージリソースのみを解放します。

void Dispose( bool disposing)

{

if (disposing)

{

//

}



//

}



* This source code was highlighted with Source Code Highlighter .

5.（オプション）クラスにはファイナライザを含めることができ、パラメータとしてfalseを渡してDispose （ bool disposing ）を呼び出すことができます。

~Boo()

{

Dispose( false /*not called by user directly*/ );

}



* This source code was highlighted with Source Code Highlighter .

このクラスのコンストラクターが例外をスローした場合、部分的に構築されたオブジェクトに対してもファイナライザーを呼び出すことができることを忘れないでください。 そのため、アンマネージリソースクリーンアップコードでは、リソースがまだキャプチャされていないことを考慮する必要があります（****）。



6.（オプション）クラスには、オブジェクトのリソースがすでに解放されていることを示すbool _disposed フィールドが含まれる場合があります。 使い捨てクラスは、静かにDisposeメソッドの繰り返し呼び出しを許可し、他のパブリックメソッドまたはプロパティにアクセスするときに例外をスローする必要があります（オブジェクトの不変式は既に破棄されているため）。

void Dispose( bool disposing)

{

if (disposed)

return ; //

//

disposed = true ;

}



public void SomeMethod()

{

if (disposed)

throw new ObjectDisposedException();

}



* This source code was highlighted with Source Code Highlighter .

7.（オプション）前の6つのポイントが少なく、よりエキゾチックにしたい場合、クラスはCriticalFinalizerObjectから継承できます。 このクラスからの継承により、追加の保証が得られます。

1. このようなクラスのファイナライザーは、インスタンスの構築時にJITコンパイラーによってすぐにコンパイルされ、必要に応じて遅延されません。 これにより、メモリが大幅に不足している場合でも、ファイナライザを正常に実行できます。
   
   
2. 既に述べたように、CLRはファイナライザーの呼び出し順序を保証しないため、ファイナライザー内で、管理されていないリソースを含む他のオブジェクトにアクセスすることはできません。 ただし、CLRは、「単なる致命的な」オブジェクトのファイナライザーがCriticalFinalizerObjectの継承者の前に呼び出されることを保証します。 これにより、特に、クラスのファイナライザー（ CriticalFinalizerObjectを継承しない場合）からSafeHandleフィールドにアクセスすることができます。SafeHandleフィールドは後で確実にリリースされます。
   
   
3. そのようなクラスのファイナライザは、アプリケーションドメインの緊急アンロードの場合でも呼び出されます。
   
   

// , ?

class Foo : CriticalFinalizerObject {}



* This source code was highlighted with Source Code Highlighter .

廃棄パターンの実用的な外観

.NETでリソースを操作するのが不当に複雑であると思われる場合、これについて2つのニュースがあります。1つは良いことであり、もう1つはあまり良くありません。 「本当にない」というニュースは、ここで説明するよりもリソースの操作が難しいことです（*****）。良いことは、ほとんどの場合、この複雑さがすべて私たちに関係ないことです。



Disposeパターン実装の全体的な複雑さは、同じクラス（またはクラス階層）が管理対象リソースと管理対象外リソースの両方を同時に含むことができるという仮定に関連しています。 しかし、管理されていないリソースをビジネスロジッククラスに直接保存する必要がある理由について考えてみましょう。 しかし、悪名高い単一責任原則（SRP）と常識はどうでしょうか？ 前述のRAIIイディオムは何十年も使用されており、そのような場合にのみ設計されています。管理されていないリソースがある場合は、直接操作するのではなく、管理シェルでラップして既に操作します。



.NET Frameworkを見ると、ここでこのアプローチが使用されていることがわかります。すべてのリソースについて、リソースを操作する複雑さのすべてを隠すシェルが作成され、ユーザーにリソースを明示的にクリアするDisposeメソッドの呼び出しのみを提供します（そして、ファイナライザー、念のため）。 さらに、オペレーティングシステムのほとんどの管理されていないリソースについては、そのようなシェルは既に作成されており、車輪を再発明する必要はありません。



これらすべてが、 ビジネスロジックと、コード内でアンマネージリソースを操作するためのロジックを混在させる必要がないという事実につながります 。 それと別のものはそれ自体かなり難しく、別のクラスに値します。 したがって、このパターンは非常にまれなケース（クラスにマネージリソースとアンマネージリソースの両方を含めることができる）に対して「最適化」されている一方で、クラスにマネージリソースのみが含まれる最も一般的なケースは実装と保守が非常に不便です。

廃棄パターンの簡易バージョン

あなたと私が誰もマネージドリソースとアンマネージドリソースを1か所に混在させないことを知っているのであれば、コードでこれを明示的に実装してみませんか？ Disposeメソッドを終了し、追加のDisposeメソッドの代わりに完全に聞こえないブール型パラメーターを使用して、仮想DisposeManagedResourcesメソッドを追加します。 このメソッドの名前から、マネージリソースを解放する必要があることが明確にわかります。 このメソッドのアクセス修飾子は、 Dispose（ bool）メソッドに似ている必要があります。 封印されていないクラスには保護された 仮想 、封印されたクラスにはプライベート 。

class SomethingWithManagedResources : IDisposable

{

public void Dispose()

{

// Dispose(true) GC.SuppressFinalize()

DisposeManagedResources();

}



// ,

protected virtual void DisposeManagedResources() {}

}



* This source code was highlighted with Source Code Highlighter .

一見、このアプローチは実際的すぎるように思えるかもしれませんが、ご自身で判断してください。「 Framework Design Guidelines 」の本には、Disposeパターンの説明に向けられた20ページがありますが、著者は、絶対に必要な場合にのみファイナライザを追加することを推奨しています。 同時に、1つのクラスに2種類のリソースを混在させることは悪いことですが、それでも禁止ではなく奨励するパターンに従っています。

おわりに

他の多くのプロジェクトで使用されるライブラリクラスまたはビジネスクラスを開発する場合、上記のすべての原則に従うことは非常に合理的です。 再利用可能なコードには他の要件もあり、設計時には他の原則に従う必要があります。メンテナンスコストよりも、そのようなクラスの使いやすさと拡張性がはるかに重要です。



ユーザー数が限られたビジネスロジッククラスまたは単純なライブラリを設計している場合、「標準」にだまされることはできませんが、マネージリソースでのみ機能するこのパターンの簡易バージョンを使用してください。



------------------------------



（*）C ++では、C＃とは異なり、メモリもリソースです。 したがって、C ++のRAIIイディオムは、動的に割り当てられたメモリの解放と、OS記述子やソケットなどの他のリソースの解放の両方に使用されます。



（**）Java 7では、C＃：try-with-resourceステートメントを使用した場合と同様のデザインが最終的に登場しました。



（***）残念ながら、C＃では、ファイナライザ（チルダの後にクラス名が続く）の最終構文が選択されます。これは、C ++のデストラクタに使用されます。 しかし、デストラクタは決定論的なリソースの解放を意味しますが、ファイナライザはそうではないため、デストラクタとファイナライザのセマンティクスは非常に異なります。



（***）はい、これは.NETとC ++の動作における別の違いです。 後者では、デストラクタは完全に構築されたオブジェクトに対してのみ呼び出されますが、デストラクタは完全に構築されたすべてのフィールドに対して呼び出されます。



（****）たとえば、ここでは、例外が発生したときに「リソースリーク」を取得する方法や、 IDisposableインターフェイスを実装する変更可能な意味のあるタイプの問題については説明しませんでした。 これについては、すでに「 例外のセキュリティ保証 」と「 可変の重要なタイプの危険性について 」のノートですでに書いています。