web-dev-qa-db-ja.com

IEnumerable vs ICollection vs IListを使用したカスタムコレクション

独自のカスタムGenericCollectionクラスを設計する必要があります。これで、IEnumerable、ICollection、およびIListを使用して導出するためのオプションがたくさんあります。これらには、後でいくつかの追加機能が提供されます。

私がIEnumerable<T>を使用する場合、この場合のように実際にコレクションを保持するようにオブジェクトを宣言する必要があるかもしれないことに少し混乱しています_list。

public class GenericCollection<T> : IEnumerable<T>
{
    private List<T> _list;
    //...
}

ただし、ICollection<T>またはIList<T>を使用する場合、Listオブジェクトを暗黙的に使用できるため、宣言する必要はありません。

public class GenericCollection<T> : IList<T>
{
    // no need for List object
    //private List<T> _list; 
    //...
}

パフォーマンスに関してこれら2つのアプローチの違いは何ですか？

特に、独自のコレクションをデザインする場合、それぞれのシナリオが好まれます。性能の良い軽量コレクションに興味があります。私はこれをIEnumerable<T>を使用して達成できると思いますが、それを実行するいくつかの強力な理由とどの程度正確に一致しますか？

既存の投稿をいくつか確認しましたが、必要な情報を提供しているものはありません。

'IList'対 'ICollection'対 'Collection'を返す

c#ienumerableilisticollectioncustom-collection
25
Furqan Safdar

IEnumerable、ICollection、およびIList（通常、I接頭辞を持つすべての型）は、単なる interfaces です。それらはあなたがあなたのクラスが何をするかを公開することを可能にします、しかしあなたが inherit クラスである場合とは異なり、インターフェースはあなたがしなければならないと言うもののデフォルト実装を提供しません。

どのインターフェースを選択するかに関しては、ここにクイックガイドがあります：

  • IListは、インデックスでアクセスできるICollectionです。
  • ICollectionはIEnumerableであり、Add、Remove、Countなどに簡単にアクセスできます。
  • IEnumerableは、列挙するまでそれらのリストが存在しなくても、列挙できるものです。

コレクション用に拡張する（またはほとんどのロジックを実行するプライベートフィールドとして保持する）ことができるクラスには、List<T>、Collection<T>（IList<T>を実装する）がありますが、オーバーライドする実装へのアクセス。これらの2つの大きな違いについては、 Collection <T>とList <T>のどちらをインターフェイスで使用する必要がありますか？ を参照してください）ObservableCollection<T>、またはリストではないコレクション、Dictionary<T, U>やHashSet<T>など。これらの詳細については、クラスのMSDNドキュメントを参照してください。

51
Tim S.

まず、これらのインターフェイスを実際に選択する必要はありません。必要に応じて、3つすべてを実装できます。次に、IEnumerableを実装するために、基になるリストを公開する必要はありません。基になるリストの列挙子を使用するメソッドのみを実装できます。

パフォーマンスに関しては、影響が大きいとは思えません。機能的に必要なものに焦点を当てます。確実に知る唯一の方法は測定することです。

1
Rik

パフォーマンスは、実装されているインターフェイスに依存する可能性はほとんどありません。むしろ、特定の目標を達成するためにプロセッサが実行しなければならない命令の数に依存します。 IEnumerableを実装してリストをラップすると、リストへの呼び出しを単に伝播するAdd/Remove/this []メソッドを作成することになり、パフォーマンスのオーバーヘッドが増加します。したがって、私は何の測定もしませんでしたが、継承アプローチはおそらく非常に高速です。

ただし、通常、このような詳細は、可能なすべてのCPUサイクルを節約するという極端な必要性があるリアルタイムアプリケーションでのみ重要です。 Eric Lippertはそのような詳細に注意を払うことについて素晴らしい記事を持っています： http://blogs.msdn.com/b/ericlippert/archive/2003/10/17/53237.aspx 。一般に、パフォーマンスの詳細よりも、アプリケーションのビジネスロジックとアーキテクチャによりよく適合するアプローチを使用するほうがよいでしょう。

0
Andrew Sklyarevsky