IEnumerableの複数の列挙の可能性に関する警告の処理

私のコードでは、IEnumerable<>数回使用する必要があるため、「可能性のある複数の列挙」のResharperエラーが発生しますIEnumerable。

サンプルコード：

public List<object> Foo(IEnumerable<object> objects)
{
    if (objects == null || !objects.Any())
        throw new ArgumentException();

    var firstObject = objects.First();
    var list = DoSomeThing(firstObject);        
    var secondList = DoSomeThingElse(objects);
    list.AddRange(secondList);

    return list;
}

• objectsパラメータをに変更してList、考えられる複数の列挙を回避できますが、処理できる最高のオブジェクトを取得できません。
• 私が行うことができますもう一つは、変換することであるIEnumerableにListメソッドの最初に：

 public List<object> Foo(IEnumerable<object> objects)
 {
    var objectList = objects.ToList();
    // ...
 }

しかし、これはただ厄介なことです。

このシナリオで何をしますか？

IEnumerableパラメータとして受け取ることの問題は、呼び出し側に「これを列挙したい」と伝えることです。何回列挙したいかは伝えません。

オブジェクトパラメータをListに変更して、複数の列挙を回避できますが、処理できる最も高いオブジェクトを取得できません。

最高のオブジェクトを取るという目標は高貴ですが、あまりにも多くの仮定の余地があります。誰かにLINQ to SQLクエリをこのメソッドに渡してもらいますか？あなたがそれを2回列挙するだけです（毎回異なる可能性のある結果を得る可能性がありますか？）

ここでセマンティックスが欠落しているのは、メソッドの詳細を読むのに時間がかからない呼び出し元は、一度しかイテレートしないと想定する可能性があるため、高価なオブジェクトが渡されるためです。メソッドシグネチャはどちらの方法も示していません。

メソッドのシグネチャをIList/に変更ICollectionすることで、少なくとも呼び出し側に期待値を明確にし、コストのかかる間違いを回避できます。

それ以外の場合、メソッドを確認するほとんどの開発者は、一度しか反復しないと想定するかもしれません。を取ることIEnumerableが非常に重要な場合.ToList()は、メソッドの開始時にを行うことを検討する必要があります。

残念です。.NETには、IEnumerable + Count + Indexerのインターフェイスがなく、Add / Removeなどのメソッドがないため、この問題を解決できると思います。

データが常に反復可能である場合、おそらくそれについて心配する必要はありません。ただし、アンロールすることもできます。これは、受信データが大きい可能性がある場合（たとえば、ディスク/ネットワークからの読み取り）に特に役立ちます。

if(objects == null) throw new ArgumentException();
using(var iter = objects.GetEnumerator()) {
    if(!iter.MoveNext()) throw new ArgumentException();

    var firstObject = iter.Current;
    var list = DoSomeThing(firstObject);  

    while(iter.MoveNext()) {
        list.Add(DoSomeThingElse(iter.Current));
    }
    return list;
}

注DoSomethingElseのセマンティクスを少し変更しましたが、これは主に展開された使用法を示すためです。たとえば、イテレータを再ラップできます。イテレータブロックにすることもできます。その後はありませんlist- yield return返されるリストに追加するのではなく、取得したアイテムを取得します。

メソッドシグネチャでの代わりにIReadOnlyCollection<T>またはIReadOnlyList<T>を使用IEnumerable<T>すると、反復する前にカウントを確認する必要がある場合や、他の理由で複数回反復する必要がある場合があることを明示する利点があります。

ただし、インターフェイスを使用するようにコードをリファクタリングしようとすると問題が発生する大きな欠点があり、たとえば、動的プロキシにテストしやすく、フレンドリーにすることができます。重要な点は、IList<T>から継承されないことIReadOnlyList<T>、そして他のコレクションとそれぞれの読み取り専用インターフェースについても同様です。（要するに、これは.NET 4.5が以前のバージョンとのABI互換性を維持したかったためです。しかし、彼らは.NETコアでそれを変更する機会すら持っていませんでした。）

これはIList<T>、プログラムのある部分からを取得し、それをを期待する別の部分に渡したいIReadOnlyList<T>場合はできないことを意味します。ただし、をIList<T>として渡すことはできIEnumerable<T>ます。

最後に、IEnumerable<T>は、すべてのコレクションインターフェイスを含むすべての.NETコレクションでサポートされる唯一の読み取り専用インターフェイスです。いくつかのアーキテクチャーの選択から自分自身をロックアウトしていることに気づくと、他のどの代替手段でも戻ってきます。したがって、読み取り専用のコレクションが必要なだけであることを表すために、関数のシグネチャで使用するのが適切なタイプだと思います。

（IReadOnlyList<T> ToReadOnly<T>(this IList<T> list)基礎となる型が両方のインターフェースをサポートしている場合は、単純なキャストで拡張メソッドをいつでも作成できますが、IEnumerable<T>常に互換性があるため、リファクタリング時にどこにでも手動で追加する必要があることに注意してください。）

これは絶対的なものではないため、偶発的な複数の列挙が障害となるデータベースを多用するコードを作成している場合は、別のトレードオフを好むかもしれません。

Marc Gravellによる回答が複数の列挙を防ぐことを本当に目的とする場合は、読み取る必要がありますが、同じセマンティクスを維持するには、冗長なAnyとを削除してFirst、次のようにします。

public List<object> Foo(IEnumerable<object> objects)
{
    if (objects == null)
        throw new ArgumentNullException("objects");

    var first = objects.FirstOrDefault();

    if (first == null)
        throw new ArgumentException(
            "Empty enumerable not supported.", 
            "objects");

    var list = DoSomeThing(first);  

    var secondList = DoSomeThingElse(objects);

    list.AddRange(secondList);

    return list;
}

これは、あなたIEnumerableが一般的ではないか、少なくとも参照型に制限されていることを前提としています。

通常、この状況では、IEnumerableとIListでメソッドをオーバーロードします。

public static IEnumerable<T> Method<T>( this IList<T> source ){... }

public static IEnumerable<T> Method<T>( this IEnumerable<T> source )
{
    /*input checks on source parameter here*/
    return Method( source.ToList() );
}

メソッドの概要コメントで、IEnumerableを呼び出すと.ToList（）が実行されることを説明します。

プログラマーは、複数の操作が連結されている場合、より高いレベルで.ToList（）を選択し、IListオーバーロードを呼び出すか、IEnumerableオーバーロードにそれを処理させることができます。

最初の要素のみをチェックする必要がある場合は、コレクション全体を反復せずにそれを覗くことができます。

public List<object> Foo(IEnumerable<object> objects)
{
    object firstObject;
    if (objects == null || !TryPeek(ref objects, out firstObject))
        throw new ArgumentException();

    var list = DoSomeThing(firstObject);
    var secondList = DoSomeThingElse(objects);
    list.AddRange(secondList);

    return list;
}

public static bool TryPeek<T>(ref IEnumerable<T> source, out T first)
{
    if (source == null)
        throw new ArgumentNullException(nameof(source));

    IEnumerator<T> enumerator = source.GetEnumerator();
    if (!enumerator.MoveNext())
    {
        first = default(T);
        source = Enumerable.Empty<T>();
        return false;
    }

    first = enumerator.Current;
    T firstElement = first;
    source = Iterate();
    return true;

    IEnumerable<T> Iterate()
    {
        yield return firstElement;
        using (enumerator)
        {
            while (enumerator.MoveNext())
            {
                yield return enumerator.Current;
            }
        }
    }
}

まず、その警告は必ずしもそれほど意味がないわけではありません。パフォーマンスのボトルネックではないことを確認した後、私は通常それを無効にしました。これは単にIEnumerableが2回評価されることを意味しevaluationます。通常、それ自体に長い時間がかからない限り、問題はありません。時間がかかる場合でも、この場合、最初に使用するのは1つの要素だけです。

このシナリオでは、強力なlinq拡張メソッドをさらに活用することもできます。

var firstObject = objects.First();
return DoSomeThing(firstObject).Concat(DoSomeThingElse(objects).ToList();

IEnumerable面倒な場合、この場合は一度だけを評価することができますが、最初にプロファイルを作成して、それが本当に問題かどうかを確認します。