Попередження про обробку для можливого багаторазового перерахування 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 запит SQL до цього методу, тільки ви перерахували його вдвічі (отримуючи потенційно різні результати щоразу?)

Семантична відсутність тут полягає в тому, що абонент, який, можливо, не потребує часу, щоб прочитати деталі методу, може припустити, що ви повторите лише один раз - тож вони передадуть вам дорогий об’єкт. Ваш підпис методу не вказує жодного способу.

Змінивши підпис методу на IList/ ICollection, ви принаймні зрозумієте абоненту, які ваші очікування, і вони зможуть уникнути дорогих помилок.

В іншому випадку більшість розробників, які шукають метод, можуть припустити, що ви повторите лише один раз. Якщо прийом IEnumerableнастільки важливий, вам варто подумати про те, як зробити .ToList()на початку методу.

Прикро. NET не має інтерфейсу, який є IEnumerable + Count + Indexer, без методів Add / Remove etc., що, як я підозрюю, вирішив би цю проблему.

Якщо ваші дані завжди будуть повторюватися, можливо, не переживайте про це. Однак ви можете також його скасувати - це особливо корисно, якщо вхідні дані можуть бути великими (наприклад, читання з диска / мережі):

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 або дозволити моєму IEsumerable перевантаження подбати про це.

Якщо вам потрібно лише перевірити перший елемент, ви можете зазирнути на нього, не повторюючи всю колекцію:

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один раз оцінити в цьому випадку деякі клопоти, але спершу профайл і побачити, чи справді це проблема.