Обработка предупреждения о возможном множественном перечислении 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в качестве параметра заключается в том, что он говорит вызывающим абонентам «Я хочу перечислить это». Это не говорит им, сколько раз вы хотите перечислить.

Я могу изменить параметр objects на List и затем избежать возможного многократного перечисления, но тогда я не получу самый высокий объект, который смогу обработать .

Цель взятия самого высокого объекта благородна, но она оставляет место для слишком многих предположений. Вы действительно хотите, чтобы кто-то передавал запрос LINQ to SQL этому методу, только для того, чтобы вы дважды его перечислили (каждый раз получая потенциально разные результаты?)

Семантическая пропущенность здесь заключается в том, что вызывающая сторона, которая, возможно, не тратит время на чтение подробностей метода, может предположить, что вы выполняете итерацию только один раз - поэтому они передают вам дорогой объект. Ваша подпись метода не указывает ни того, ни другого.

Изменив сигнатуру метода на 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>это всегда совместимо.)

Как всегда, это не является абсолютным, если вы пишете код, насыщенный базой данных, где случайное множественное перечисление может привести к катастрофе, вы можете предпочесть другой компромисс.

Если цель на самом деле состоит в том, чтобы предотвратить множественные перечисления, то следует прочитать ответ Марка Гравелла, но, сохраняя ту же семантику, вы можете просто удалить избыточность 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оценивается дважды, что обычно не является проблемой, если толькоevaluation само себе не занимает много времени. Даже если это займет много времени, в этом случае вы используете только один элемент в первый раз.

В этом сценарии вы также можете использовать более мощные методы расширения linq.

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

В этом случае можно оценить только IEnumerableодин раз с некоторыми трудностями, но сначала проанализировать и посмотреть, действительно ли это проблема.