Obsługa ostrzeżenia o możliwym wielokrotnym wyliczeniu IEnumerable

W moim kodzie muszę używać IEnumerable<>kilka razy, dlatego otrzymuję błąd Resharper „Możliwe wielokrotne wyliczenie IEnumerable”.

Przykładowy kod:

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

• Mogę zmienić objectsparametr na, Lista następnie uniknąć możliwego wielokrotnego wyliczenia, ale wtedy nie otrzymuję najwyższego obiektu, który mogę obsłużyć.
• Inną rzeczą, którą mogę zrobić, to przekonwertować IEnumerableaby Listna początku metody:

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

Ale to jest po prostu niezręczne .

Co byś zrobił w tym scenariuszu?

Problem z przyjmowaniem IEnumerablejako parametru polega na tym, że mówi on dzwoniącym „chcę to wyliczyć”. Nie mówi im, ile razy chcesz wyliczyć.

Mogę zmienić parametr obiektów na List, a następnie uniknąć możliwego wielokrotnego wyliczenia, ale wtedy nie otrzymuję najwyższego obiektu, który mogę obsłużyć .

Cel wzięcia najwyższego przedmiotu jest szlachetny, ale pozostawia miejsce na zbyt wiele założeń. Czy naprawdę chcesz, aby ktoś przekazał kwerendę LINQ do SQL do tej metody, abyś mógł ją wyliczyć dwukrotnie (uzyskiwanie potencjalnie różnych wyników za każdym razem?)

Semantyczny brak tutaj polega na tym, że osoba dzwoniąca, która być może nie potrzebuje czasu na przeczytanie szczegółów metody, może założyć, że wykonasz iterację tylko raz - więc przekażą ci drogi przedmiot. Podpis metody nie wskazuje w żaden sposób.

Zmieniając sygnaturę metody na IList/ ICollection, przynajmniej sprawisz, że dzwoniący będzie bardziej przejrzysty, jakie są twoje oczekiwania, a także pozwoli uniknąć kosztownych błędów.

W przeciwnym razie większość programistów przyglądających się metodzie może założyć, że wykonasz iterację tylko raz. Jeśli podjęcie IEnumerablejest tak ważne, powinieneś rozważyć zrobienie tego .ToList()na początku metody.

Szkoda, że ​​.NET nie ma interfejsu, który jest IEnumerable + Count + Indexer, bez metod Add / Remove etc., co, jak podejrzewam, rozwiązałoby ten problem.

Jeśli Twoje dane zawsze będą powtarzalne, być może nie przejmuj się nimi. Można go jednak również rozwinąć - jest to szczególnie przydatne, jeśli przychodzące dane mogą być duże (na przykład odczyt z dysku / sieci):

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

Uwaga: Zmieniłem nieco semantię DoSomethingElse, ale ma to głównie na celu pokazanie rozwiniętego użycia. Możesz na przykład ponownie owinąć iterator. Możesz zrobić z niego również blok iteratora, co może być miłe; wtedy nie ma list- i dostaniesz yield returnprzedmioty, jak je zdobędziesz, zamiast dodawać do listy, która ma zostać zwrócona.

Użycie IReadOnlyCollection<T>lub IReadOnlyList<T>w podpisie metody zamiast IEnumerable<T>, ma tę zaletę, że wyraźnie oznacza, że ​​może być konieczne sprawdzenie liczby przed iteracją lub wielokrotne iterowanie z innego powodu.

Mają jednak ogromny minus, który spowoduje problemy, jeśli spróbujesz przeredagować swój kod, aby używać interfejsów, na przykład aby uczynić go bardziej testowalnym i przyjaznym dla dynamicznego proxy. Kluczową kwestią jest to, że IList<T>nie dziedziczyIReadOnlyList<T> , i podobnie dla innych kolekcji i ich odpowiednich interfejsów tylko do odczytu. (Krótko mówiąc, to dlatego, że .NET 4.5 chciał zachować zgodność ABI z wcześniejszymi wersjami. Ale nawet nie skorzystali z okazji, aby zmienić to w .NET core. )

Oznacza to, że jeśli dostaniesz IList<T>z jakiejś części programu i chcesz przekazać ją do innej części, która oczekuje IReadOnlyList<T>, nie możesz! Możesz jednak przekazać IList<T>jakoIEnumerable<T> .

Ostatecznie IEnumerable<T>jest jedynym interfejsem tylko do odczytu obsługiwanym przez wszystkie kolekcje .NET, w tym wszystkie interfejsy kolekcji. Każda inna alternatywa wróci, by cię ugryźć, gdy zdasz sobie sprawę, że zablokowałeś się przed niektórymi opcjami architektury. Sądzę więc, że to właściwy typ w sygnaturach funkcji, aby wyrazić, że chcesz tylko kolekcję tylko do odczytu.

(Pamiętaj, że zawsze możesz napisać IReadOnlyList<T> ToReadOnly<T>(this IList<T> list)metodę rozszerzenia, która po prostu rzutuje, jeśli typ bazowy obsługuje oba interfejsy, ale musisz dodać ją ręcznie wszędzie podczas refaktoryzacji, gdzie jak IEnumerable<T>zawsze jest kompatybilna).

Jak zawsze nie jest to absolutne, jeśli piszesz obszerny kod bazy danych, w którym przypadkowe wielokrotne wyliczenie byłoby katastrofą, możesz preferować inny kompromis.

Jeśli celem jest naprawdę zapobieganie wielokrotnym wyliczeniom, to odpowiedź należy do Marca Gravella, ale zachowując tę ​​samą semantykę, możesz po prostu usunąć zbędne Anyi Firstwywołania i zastosować:

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

Zauważ, że zakłada to, że nie jesteś IEnumerableogólny lub przynajmniej jest ograniczony do typu odniesienia.

W tej sytuacji zwykle przeciążam moją metodę IEnumerable i 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() );
}

Staram się wyjaśnić w komentarzach podsumowujących metody, że wywołanie IEnumerable wykona funkcję .ToList ().

Programista może wybrać opcję .ToList () na wyższym poziomie, jeśli wiele operacji jest konkatenowanych, a następnie wywołać przeciążenie IList lub pozwolić, aby moje IEnumerable przeciążenie się tym zajęło.

Jeśli chcesz tylko sprawdzić pierwszy element, możesz zerknąć na niego bez iteracji całej kolekcji:

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

Po pierwsze, to ostrzeżenie nie zawsze tyle znaczy. Zwykle wyłączałem go po upewnieniu się, że nie jest to szyjka butelki wydajności. Oznacza to tylko, że IEnumerableocena jest oceniana dwukrotnie, co zwykle nie stanowi problemu, chyba że evaluationsamo zajmuje dużo czasu. Nawet jeśli zajmuje to dużo czasu, w tym przypadku używasz tylko jednego elementu za pierwszym razem.

W tym scenariuszu można jeszcze bardziej wykorzystać potężne metody rozszerzenia linq.

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

W IEnumerabletym przypadku można ocenić tylko raz z pewnym kłopotem, ale najpierw profiluj i sprawdź, czy to naprawdę problem.