Handhabungswarnung für mögliche mehrfache Aufzählung von IEnumerable

In meinem Code muss ein IEnumerable<>mehrmals verwendet werden, daher wird der Resharper-Fehler "Mögliche Mehrfachaufzählung von IEnumerable" angezeigt .

Beispielcode:

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;
}

• Ich kann den objectsParameter so ändern Listund dann die mögliche Mehrfachaufzählung vermeiden, aber dann erhalte ich nicht das höchste Objekt, das ich verarbeiten kann.
• Eine andere Sache, die ich tun kann, ist, das IEnumerablezu ListBeginn der Methode in zu konvertieren :

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

Das ist aber nur umständlich .

Was würden Sie in diesem Szenario tun?

Das Problem bei der Verwendung IEnumerableals Parameter besteht darin, dass Anrufer erfahren, dass ich dies aufzählen möchte. Es sagt ihnen nicht, wie oft Sie aufzählen möchten.

Ich kann den Objektparameter in Liste ändern und dann die mögliche Mehrfachaufzählung vermeiden, aber dann erhalte ich nicht das höchste Objekt, das ich verarbeiten kann .

Das Ziel, das höchste Objekt zu nehmen, ist nobel, lässt aber Raum für zu viele Annahmen. Möchten Sie wirklich, dass jemand eine LINQ to SQL-Abfrage an diese Methode übergibt, nur damit Sie sie zweimal aufzählen (jedes Mal möglicherweise unterschiedliche Ergebnisse erhalten?)

Die hier fehlende Semantik besteht darin, dass ein Aufrufer, der sich möglicherweise nicht die Zeit nimmt, die Details der Methode zu lesen, davon ausgeht, dass Sie nur einmal iterieren - er übergibt Ihnen also ein teures Objekt. Ihre Methodensignatur gibt keinen Weg an.

Indem Sie die Methodensignatur in IList/ ändern ICollection, machen Sie dem Anrufer zumindest klarer, was Ihre Erwartungen sind, und sie können kostspielige Fehler vermeiden.

Andernfalls gehen die meisten Entwickler, die sich die Methode ansehen, möglicherweise davon aus, dass Sie nur einmal iterieren. Wenn IEnumerablees so wichtig ist, eine zu nehmen, sollten Sie dies .ToList()zu Beginn der Methode in Betracht ziehen .

Es ist eine Schande, dass .NET keine Schnittstelle hat, die IEnumerable + Count + Indexer ist, ohne Methoden zum Hinzufügen / Entfernen usw., was meines Erachtens dieses Problem lösen würde.

Wenn Ihre Daten immer wiederholbar sind, machen Sie sich vielleicht keine Sorgen. Sie können es jedoch auch abrollen. Dies ist besonders nützlich, wenn die eingehenden Daten sehr groß sein können (z. B. Lesen von der Festplatte / dem Netzwerk):

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;
}

Hinweis: Ich habe die Semantik von DoSomethingElse ein wenig geändert, dies dient jedoch hauptsächlich dazu, die nicht gerollte Verwendung anzuzeigen. Sie können den Iterator beispielsweise erneut umbrechen. Sie könnten es auch zu einem Iteratorblock machen, was nett sein könnte; dann gibt es keine list- und Sie würden yield returndie Artikel so erhalten, wie Sie sie erhalten, anstatt sie einer Liste hinzuzufügen, die zurückgegeben werden soll.

Die Verwendung von IReadOnlyCollection<T>oder IReadOnlyList<T>in der Methodensignatur anstelle von IEnumerable<T>hat den Vorteil, dass explizit angegeben wird, dass Sie möglicherweise die Anzahl vor dem Iterieren überprüfen oder aus einem anderen Grund mehrmals iterieren müssen.

Sie haben jedoch einen großen Nachteil, der zu Problemen führen kann, wenn Sie versuchen, Ihren Code so umzugestalten, dass er Schnittstellen verwendet, um ihn beispielsweise testbarer und für dynamisches Proxying benutzerfreundlicher zu machen. Der entscheidende Punkt ist, dass IList<T>nicht vonIReadOnlyList<T> und für andere Sammlungen und ihre jeweiligen schreibgeschützten Schnittstellen geerbt wird. (Kurz gesagt, dies liegt daran, dass .NET 4.5 die ABI-Kompatibilität mit früheren Versionen beibehalten wollte. Sie nutzten jedoch nicht einmal die Gelegenheit, dies in .NET Core zu ändern. )

Dies bedeutet, dass Sie dies nicht können, wenn Sie eine IList<T>von einem Teil des Programms erhalten und an einen anderen Teil übergeben möchten, der eine erwartet IReadOnlyList<T>! Sie können jedoch eine IList<T>als übergebenIEnumerable<T> .

Letztendlich IEnumerable<T>ist dies die einzige schreibgeschützte Schnittstelle, die von allen .NET-Sammlungen einschließlich aller Sammlungsschnittstellen unterstützt wird. Jede andere Alternative wird Sie beißen, wenn Sie feststellen, dass Sie sich von einigen Architekturentscheidungen ausgeschlossen haben. Ich denke, es ist der richtige Typ für Funktionssignaturen, um auszudrücken, dass Sie nur eine schreibgeschützte Sammlung wünschen.

(Beachten Sie, dass Sie immer eine IReadOnlyList<T> ToReadOnly<T>(this IList<T> list)Erweiterungsmethode schreiben können, die einfach umgewandelt wird, wenn der zugrunde liegende Typ beide Schnittstellen unterstützt. Sie müssen sie jedoch beim Refactoring überall manuell hinzufügen, wo dies IEnumerable<T>immer kompatibel ist.)

Wie immer ist dies kein absoluter Kompromiss. Wenn Sie datenbankintensiven Code schreiben, bei dem eine versehentliche Mehrfachaufzählung eine Katastrophe darstellen würde, bevorzugen Sie möglicherweise einen anderen Kompromiss.

Wenn das Ziel wirklich darin besteht, mehrere Aufzählungen zu verhindern, ist die Antwort von Marc Gravell die zu lesende, aber wenn Sie dieselbe Semantik beibehalten, können Sie einfach die Redundanz Anyund die FirstAufrufe entfernen und fortfahren mit:

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;
}

Beachten Sie, dass dies voraussetzt, dass Sie IEnumerablenicht generisch sind oder zumindest ein Referenztyp sein müssen.

Normalerweise überlade ich meine Methode in dieser Situation mit IEnumerable und 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() );
}

Ich erkläre in den zusammenfassenden Kommentaren der Methoden, dass der Aufruf von IEnumerable eine .ToList () ausführt.

Der Programmierer kann .ToList () auf einer höheren Ebene auswählen, wenn mehrere Vorgänge verkettet werden, und dann die IList-Überladung aufrufen oder meine IEnumerable-Überladung dafür sorgen lassen.

Wenn Sie nur das erste Element überprüfen müssen, können Sie einen Blick darauf werfen, ohne die gesamte Sammlung zu wiederholen:

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;
            }
        }
    }
}

Zunächst einmal bedeutet diese Warnung nicht immer so viel. Normalerweise habe ich es deaktiviert, nachdem ich sichergestellt hatte, dass es sich nicht um einen Performance-Flaschenhals handelt. Es bedeutet nur, dass das IEnumerablezweimal ausgewertet wird, was normalerweise kein Problem ist, es sei denn, dasevaluation selbst dauert lange. Auch wenn es lange dauert, verwenden Sie in diesem Fall beim ersten Mal nur ein Element.

In diesem Szenario können Sie die leistungsstarken Linq-Erweiterungsmethoden auch noch stärker nutzen.

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

Es ist IEnumerablein diesem Fall möglich, das nur einmal mit etwas Aufwand zu bewerten , aber zuerst das Profil zu erstellen und zu prüfen, ob es wirklich ein Problem ist.