クラスまたはインターフェイスのIDisposableを宣言しますか？

Question

follwing状況最低料金：

public interface ISample 
{ 
} 

public class SampleA : ISample 
{ 
    // has some (unmanaged) resources that needs to be disposed 
} 

public class SampleB : ISample 
{ 
    // has no resources that needs to be disposed 
} 

クラスSampleAは、リソースを解放するためのインターフェイスIDisposableインターを実装する必要があります。 次の2つの方法でこれを解決できます。それを実装するためのインタフェースISampleと力派生クラスに追加します

public class SampleA : ISample, IDisposable 
{ 
    // has some (unmanaged) resources that needs to be disposed 
} 

2：

1.クラスSampleAするために必要なインタフェースを追加します。

public interface ISample : IDisposable 
{ 
} 

あなたは、彼らが処分することは何もない場合でも、IDisposableインターを実装するために任意の実装を強制するインタフェースにそれを置く場合。一方、インターフェイスの具体的な実装にはdispose/usingブロックが必要であり、クリーンアップのためにIDisposableとしてキャストする必要はありません。両方の方法でさらにいくつかの長所/短所があるかもしれません...なぜ、他の方法より優先される方法を使用するように提案しますか？

Answer 1

すべてのあなたのインターフェイスにusing(){}パターンを適用した場合のインタフェースを設計親指のルールは、「使いやすさ」使いやすさの-実装」上をを好むことであるので、それはISampleがIDisposableから派生持つのがベストです"。少なくともいくつかのいくつかの実施例は、IDisposableを実施する可能性がある場合

Answer 2

個人的には、すべてISampleさんが使い捨てでなければならない場合は、私はそれをインターフェースに置いておきます。

あなたは後者の場合のように聞こえます。

Answer 3

個人的には、2つの具体例を作成しない限り、私は1を選択します。 2人の良い例はIListです。

IListは、コレクション用のインデクサーを実装する必要があることを意味します。 しかし、IListは実際にはIEnumerableであることを意味し、クラスにはGetEnumerator()が必要です。あなたがISampleを実装するクラスは、あなたのインターフェイスを実装していないすべてのクラスがIDisposableが、その後にそれらを強制しない実装している場合、IDisposableを実装する必要があるとhesistantあるあなたの場合は

。

具体的には、IDispoableに焦点を当てると、特にIDispoableは、クラスを使用しているプログラマが合理的に醜いコードを書くことを強いられます。例えば、

foreach(item in IEnumerable<ISample> items) 
{ 
    try 
    { 
     // Do stuff with item 
    } 
    finally 
    { 
     IDisposable amIDisposable = item as IDisposable; 
     if(amIDisposable != null) 
      amIDisposable.Dispose(); 
    } 
} 

だけでなく、コードは恐ろしいです、最終的にはちょうどに戻ってもDispose()た場合、そのリストのすべての反復のためのアイテムを処分するためにブロックがある確保する上で重要なパフォーマンスの低下が発生します実装。

ここにコメントの1つに答えるコードを貼り付け、読みやすくしてください。

Answer 4

IDispoableは非常に一般的なインターフェイスなので、インターフェイスを継承しても問題ありません。したがって、ISample実装の一部にノーオペレーションを実装するためには、コードの型チェックを犠牲にする必要がありません。だからこの第2の選択肢はこの観点からより良いかもしれない。

Answer 5

インターフェースIFooおそらくIDisposableを実装する必要があり、少なくともいくつかの機会にインスタンスへの最後の生き残り参照型IFooの変数またはフィールドに格納されます。いずれの実装でもIDisposableが実装されており、インスタンスがファクトリインターフェイス（IEnumerator<T>のインスタンスの場合のように、多くの場合、ファクトリインターフェイスIEnumerable<T>によって作成されます）を使用して作成される場合は、ほとんど確実にIDisposableを実装する必要があります。

IEnumerable<T>とIEnumerator<T>を比較することは有益です。 IEnumerable<T>を実装するいくつかの型もIDisposableを実装していますが、そのような型のインスタンスを作成するコードは、それらが何であるかを知り、処分が必要であることを知り、特定の型として使用します。そのようなインスタンスはタイプIEnumerable<T>として他のルーチンに渡すことができ、それらの他のルーチンはオブジェクトが最終的に処分する必要があるという手がかりを持たないだろうが、ほとんどの場合、オブジェクトへの参照を保持する最後のルーチン。対照的に、IEnumerator<T>のインスタンスは、多くの場合、IEnumerable<T>によって返されるという事実を超えて、それらのインスタンスの基礎となる型について何も知らないコードによって、作成され、使用され、最終的に放棄されます。 IEnumerable<T>.GetEnumerator()戻り実装のIEnumerator<T>の一部の実装では、それらが破棄される前にIDisposable.Disposeメソッドが呼び出されていない場合にリソースがリークし、IEnumerable<T>のパラメータを受け入れるほとんどのコードは、そのような型が渡されるかどうかを知る方法を持ちません。 IEnumerable<T>には、返されたIEnumerator<T>が廃棄される必要があるかどうかを示すためにプロパティEnumeratorTypeNeedsDisposalを含めることが可能ですが、GetEnumerator()を呼び出すルーチンが返されたオブジェクトのタイプをチェックして、IDisposableを実装しているかどうかを確認することができます。無条件にDisposeメソッドを呼び出して、何もしない可能性があります。Disposeが必要かどうかを判断し、そうでない場合にのみコールします。あなたはあなたがA.

に追加する必要がありますに興味を持っていないクライアントにメソッドを与えているインタフェースにIDisposableをを追加した場合SOLIDのInteface Segregation Principleに続いて

Answer 6

は、それとは別に、インターフェースがあるため使い捨てになることはありませんディスポーザビリティは、インターフェイスの具体的な実装に関連するものであり、インターフェイス自体では決してありません。

任意のインターフェイスは、処理する必要のある要素の有無にかかわらず、実装することができます。

Answer 7

私は、インターフェイスにIDisposableを置くといくつかの問題を引き起こす可能性があると考え始めています。これは、そのインタフェースを実装するすべてのオブジェクトの存続期間が安全に同期して終了できることを意味します。すなわち、それは誰もがこのようなコードを記述することができますし、IDisposableをサポートするためにすべての実装を必要とします。具体的な種類にアクセスしている

using (ISample myInstance = GetISampleInstance()) 
{ 
    myInstance.DoSomething(); 
} 

のみコードは、オブジェクトの寿命を制御するための正しい方法を知ることができます。たとえば、タイプが最初に処分する必要がない場合は、IDisposableをサポートしているか、使用後に非同期クリーンアッププロセスawaitingが必要になる場合があります（例：something like option 2 here）。

インターフェイスの作成者は、クラスを実装するための将来の生涯/スコープ管理の必要性をすべて予測することはできません。インタフェースの目的は、オブジェクトが一部のAPIを公開して、一部のコンシューマに役立つようにすることです。一部のインターフェイスはとなる可能性があります（IDisposableなど）。これらのインターフェイスを生涯管理とは無関係に混在させると、インターフェイスの実装を困難または不可能にすることができます。インタフェースの実装がほとんどなく、インタフェースのコンシューマとライフタイムとスコープマネージャが同じメソッドになるようにコードを構造化する場合、この区別は最初は明確ではありません。しかし、あなたがあなたのオブジェクトを周りに渡すようになると、これはより明確になります。上記のコードサンプルで

void ConsumeSample(ISample sample) 
{ 
    // INCORRECT CODE! 
    // It is a developer mistake to write “using” in consumer code. 
    // “using” should only be used by the code that is managing the lifetime. 
    using (sample) 
    { 
     sample.DoSomething(); 
    } 

    // CORRECT CODE 
    sample.DoSomething(); 
} 

async Task ManageObjectLifetimesAsync() 
{ 
    SampleB sampleB = new SampleB(); 
    using (SampleA sampleA = new SampleA()) 
    { 
     DoSomething(sampleA); 
     DoSomething(sampleB); 
     DoSomething(sampleA); 
    } 

    DoSomething(sampleB); 

    // In the future you may have an implementation of ISample 
    // which requires a completely different type of lifetime 
    // management than IDisposable: 
    SampleC = new SampleC(); 
    DoSomething(sampleC); 
    sampleC.Complete(); 
    await sampleC.Completion; 
} 

class SampleC : ISample 
{ 
    public void Complete(); 
    public Task Completion { get; } 
} 

、私はあなたが設けられた二つに追加して、寿命管理シナリオの3種類を実証しました。

1. SampleA
   は、同期using() {}サポートとIDisposableです。
2. SampleBは純粋なガベージコレクションを使用します（リソースを消費しません）。
3. SampleCは、生存期間の最後にawaitが必要です（リソースを消費し、非同期に発生した例外を吹き飛ばすことを寿命管理コードに通知するため）。寿命管理を維持することにより

を使用すると、開発者のミスを防ぐ（Dispose()に例えば、偶然の呼び出し）と、よりきれいに、将来の不測の生涯/スコープ管理パターンをサポートすることができ、あなたの他のインタフェースとは別。