3

まず、これが重複していると見なされた場合は申し訳ありません-それが一般的なトピックであることは知っていますが、調べたところ満足のいく答えが見つかりませんでした.

をいつ使用するを尋ねる質問がたくさんありますが、IDisposable私が読んだすべてのことから、作成するすべてのクラスにそれを実装しない理由がわかりません。失うものは何ですか?パフォーマンスに大きな影響がありますか?

私の理解の一部は、オブジェクトが所有する他の IDisposables を Dispose()ing することIDisposableです 。私の無知を許してください、しかしこれは与えられたオブジェクトのフィールド/プロパティにのみ適用されますか、それともそのメソッド内で作成されたオブジェクトにも適用されますか?

たとえば、Fontを実装するクラス内のメソッド内で a が作成されたがIDisposable、ブロックでFont初期化されていない場合、またはメソッドの最後に明示的に d がある場合。親/クラスがGCd/破棄されたときに破棄されますか? または、そうでなければ、決して処分されませんか?using.Dispose()IDisposableFont

脱線するつもりはありませんが、このような「キャッチオール」として機能することが本当である場合(そうでなければ破棄されないままになるエラーのある子IDisposableオブジェクトを効果的に破棄します)、その理由だけで正当化するのに十分ではありません可能な限り常に実装していIDisposableますか?

4

3 に答える 3

0

オブジェクトはIDisposable、宇宙の終わりの前に起こる必要があることを知っている場合に実装する必要があり、それらのことを確実に行うために必要な知識と推進力を持っているものは他にありません。このDisposeメソッドは、これらのことをすぐに実行したほうがよいことをオブジェクトに知らせます。

抽象型またはインターフェースはIDisposable、その型の派生または実装のインスタンスが宇宙の終わりの前に発生する必要があることを知っている可能性が高い場合に実装する必要があり参照を保持している最後のエンティティはそれがを実装するより具体的な型を実装するものとしてではなく、抽象型またはインターフェイス型から派生または実装するもののインスタンスIDisposable

継承するインターフェイスを実装する型は、他の理由があるかどうかにかかわらず、IDisposableを実装する必要があります。IDisposable

実装する理由がある型IDisposableはそうすべきです。しない、すべきでないタイプ。

補遺

常に を実装すべきではない理由を理解するには、実装IDisposableにかかる実際のコストを考慮すると役立つ場合があります。プロセッサが何もしないメソッドを呼び出すのに必要な時間Disposeは些細なことですが、それは実際の考慮事項ではありません。より大きな問題は、ほとんどのオブジェクトが次の 4 つの説明のいずれかに当てはまると考えると発生します。

  • リソースをカプセル化し、明確に定義された所有者が 1 人必要なオブジェクト

  • 変更可能な状態をカプセル化し、明確に定義された所有者が 1 人必要なオブジェクト。

  • 明確に定義された所有者を持つ必要のない不変型のオブジェクト。

  • それらを変更する可能性のあるコードに公開されることは決してなく、明確に定義された所有者を持つ必要がない可変型のインスタンス。

リソースを保持するオブジェクトの場合と同様に、変更可能なオブジェクトを正しく使用するには、通常、誰がオブジェクトを所有しているかを追跡する必要があります。同様に、変更可能な状態を持つオブジェクトが別のオブジェクトの変更可能な状態をカプセル化するために使用される場合、後者のオブジェクトを適切に使用するには、リソースを所有する他のオブジェクトをカプセル化するオブジェクトの場合と同様に、誰がそれを所有しているかを追跡する必要があります。リソースを持つオブジェクトと可変状態を持つオブジェクトの違いは、可変型のインスタンスを使用して不変オブジェクトの状態をカプセル化する場合 (インスタンスがそれを変更するコードに公開されないようにすること)、それはもはや誰が所有しているかを追跡する必要があります。対照的に、リソースを保持する他のオブジェクトをカプセル化するオブジェクトの所有権は、それらのオブジェクトが意味的に不変であっても追跡する必要があります。

于 2013-09-07T21:25:31.077 に答える