Когда использовать каждый из T[], List‹T›, IEnumerable‹T›?

Что касается производительности...

• Преобразование из списка в T[] включает в себя копирование всех данных из исходного списка во вновь выделенный массив.
• Преобразование из T[] в список также включает копирование всех данных из исходного списка во вновь выделенный список.
• Преобразование из List или T[] в IEnumerable включает приведение типов, что занимает несколько циклов процессора.
• Преобразование из IEnumerable в List включает в себя повышение приведения, что также требует нескольких циклов процессора.
• Преобразование из IEnumerable в T[] также включает повышение класса.
• Вы не можете привести IEnumerable к T[] или List, если это не было T[] или List соответственно для начала. Вы можете использовать функции ToArray или ToList, но они также приведут к созданию копии.
• Доступ ко всем значениям по порядку от начала до конца в T[] в прямом цикле будет оптимизирован для использования простой арифметики указателей, что делает его самым быстрым из всех.
• Доступ ко всем значениям по порядку от начала до конца в списке включает проверку на каждой итерации, чтобы убедиться, что вы не получаете доступ к значению за пределами массива, а затем фактический доступ к значению массива.
• Доступ ко всем значениям в IEnumerable включает создание объекта перечислителя, вызов функции Next(), которая увеличивает указатель индекса, а затем вызов свойства Current, которое дает вам фактическое значение и вставляет его в переменную, указанную в вашем операторе foreach. . В общем, это не так плохо, как кажется.
• Доступ к произвольному значению в IEnumerable включает в себя запуск с самого начала и вызов Next() столько раз, сколько вам нужно, чтобы добраться до этого значения. Как правило, это так плохо, как кажется.

По поводу идиом...

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

Например, если бы у вас была функция PrintValues, если бы она была написана как PrintValues(List‹T> values), она могла бы иметь дело только со значениями List, поэтому пользователю сначала пришлось бы преобразовать, если, например, они использовали в[]. Аналогично, если функция была PrintValues(T[] values). Но если бы это были PrintValues(значения IEnumerable‹T>), он мог бы иметь дело со списками, T[], стеками, хеш-таблицами, словарями, строками, наборами и т. д. — любой коллекцией, которая реализует IEnumerable, что практически коллекция.

Что касается внутреннего употребления...

• Используйте список, только если вы не уверены, сколько элементов должно быть в нем.
• Используйте T[], если вы знаете, сколько элементов должно быть в нем, но вам нужно получить доступ к значениям в произвольном порядке.
• Придерживайтесь IEnumerable, если это то, что вам дали, и вам просто нужно использовать его последовательно. Многие функции возвращают IEnumerables. Если вам нужно получить доступ к значениям из IEnumerable в произвольном порядке, используйте ToArray().

Кроме того, обратите внимание, что приведение типов отличается от использования ToArray() или ToList() — последнее включает в себя копирование значений, что действительно является ударом по производительности и памяти, если у вас много элементов. Первый просто означает, что «Собака — это животное, поэтому, как и любое другое животное, она может есть» (подавленное) или «Это животное оказалось собакой, поэтому оно может лаять» (подавленное). Точно так же все списки и T[] являются IEnumerables, но только некоторые IEnumerables являются списками или T[]s.

Хорошее эмпирическое правило состоит в том, чтобы всегда использовать IEnumerable (при объявлении ваших переменных/параметров метода/типов/свойств возвращаемого значения метода/и т. д.), если у вас нет веской причины не делать этого. На сегодняшний день наиболее совместим по типам с другими (особенно с расширением) методами.

Итак, у вас есть два яблока и апельсин, которые вы сравниваете.

Два яблока — это массив и список.

• Массив в C# — это массив в стиле C со встроенной сборкой мусора. Преимущество их использования в том, что у них очень мало накладных расходов, при условии, что вам не нужно перемещать вещи. Плохо то, что они не так эффективны, когда вы добавляете что-то, удаляете что-то и иным образом меняете массив, поскольку память перемешивается.

• Список — это динамический массив в стиле C# (похожий на класс vector‹> в C++). Существует больше накладных расходов, но они более эффективны, когда вам нужно много перемещать вещи, поскольку они не будут пытаться поддерживать непрерывное использование памяти.

Лучшее сравнение, которое я мог бы привести, это сказать, что массивы относятся к спискам так же, как строки к StringBuilder.

Оранжевый — это «IEnumerable». Это не тип данных, а интерфейс. Когда класс реализует интерфейс IEnumerable, он позволяет использовать этот объект в цикле foreach().

Когда вы возвращаете список (как в своем примере), вы не преобразовывали список в IEnumerable. Список уже является объектом IEnumerable.

РЕДАКТИРОВАТЬ: Когда конвертировать между двумя:

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

Надеюсь, это немного рассеет туман.

Мне кажется, проблема в том, что вы не удосужились научиться искать в массиве. Подсказка: Array.IndexOf или Array.BinarySearch в зависимости от того, отсортирован ли массив.

Вы правы в том, что преобразование в список — плохая идея: оно занимает место и время и делает код менее читаемым. Кроме того, слепое приведение к IEnumerable замедляет работу, а также полностью предотвращает использование определенных алгоритмов (таких как бинарный поиск).

Я стараюсь избегать быстрых переходов между типами данных, если этого можно избежать.

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

Когда что использовать?

Я бы предложил вернуть наиболее конкретный тип и использовать наиболее гибкий тип.

Как это:

public int[] DoSomething(IEnumerable<int> inputs)
{
    //...
}

public List<int> DoSomethingElse(IList<int> inputs)
{
    //...
}

Таким образом, вы можете вызывать методы List< T > для всего, что вы получаете от метода, в дополнение к обработке его как IEnumerable. На входах используйте максимально гибкие, чтобы не диктовать пользователям вашего метода, какую коллекцию создавать.

Вы правы, игнорируя антенны «проблемы с производительностью», пока у вас действительно не возникнет проблема с производительностью. Большинство проблем с производительностью возникает из-за слишком большого количества операций ввода-вывода, слишком большого количества блокировок или неправильного выполнения одного из них, и ни один из этих факторов не относится к данному вопросу.

Мой общий подход таков:

1. Используйте T[] для «статической» или «моментальной» информации. Используйте для вещей, где вызов .Add() в любом случае не имеет смысла, и вам не нужны дополнительные методы, которые дает вам List‹T>.
2. Примите IEnumerable‹T>, если вам все равно, что вам дано, и вам не нужен .Length/.Count с постоянным временем.
3. Возвращайте IEnumerable‹T> только тогда, когда вы выполняете простые манипуляции с вводом IEnumerable‹T> или когда вы специально хотите использовать синтаксис yield для ленивого выполнения своей работы.
4. Во всех остальных случаях используйте List‹T>. Это слишком гибко.

Следствие № 4: не бойтесь ToList(). ToList() — ваш друг. Это заставляет IEnumerable‹T> вычислять сразу (полезно, когда вы складываете несколько предложений where). Не сходите с ума с этим, но не стесняйтесь вызывать его после того, как вы создали свое полное предложение where, прежде чем делать над ним foreach (или тому подобное).

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