Должен ли я всегда возвращать IEnumerable ‹T› вместо IList ‹T›?

Это действительно зависит от того, почему вы используете этот конкретный интерфейс.

Например, IList<T> имеет несколько методов, которых нет в IEnumerable<T>:

• IndexOf(T item)
• Insert(int index, T item)
• RemoveAt(int index)

и свойства:

• T this[int index] { get; set; }

Если вам каким-либо образом нужны эти методы, то непременно верните IList<T>.

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

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

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

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

Имейте в виду, что LINQ содержит несколько уловок в рукаве и оптимизирует определенные вызовы в зависимости от типа, для которого они выполняются. Так, например, если вы выполняете Count, а базовая коллекция - это список, он НЕ будет проходить через все элементы.

Лично для ORM я бы, вероятно, придерживался Collection<T> в качестве возвращаемого значения.

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

Будьте свободны в том, что вам нужно, и четко говорите о том, что вы предоставляете.

Это зависит...

Возврат наименее производного типа (IEnumerable) оставит вам наибольшую свободу действий для изменения базовой реализации в дальнейшем.

Возврат более производного типа (IList) предоставляет пользователям вашего API больше операций над результатом.

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

Одна вещь, которую следует учитывать, заключается в том, что если вы используете оператор LINQ с отложенным выполнением для генерации вашего IEnumerable<T>, вызов .ToList() перед возвратом из вашего метода означает, что ваши элементы могут быть повторены дважды - один раз для создания списка и один раз, когда вызывающий перебирает, фильтрует или преобразует возвращаемое значение. На практике я предпочитаю избегать преобразования результатов LINQ-to-Objects в конкретный список или словарь до тех пор, пока мне это не понадобится. Если моему вызывающему абоненту нужен List, это можно сделать одним простым вызовом метода - мне не нужно принимать это решение за них, и это делает мой код немного более эффективным в случаях, когда вызывающий просто выполняет foreach.

List<T> предлагает вызывающему коду гораздо больше возможностей, таких как изменение возвращаемого объекта и доступ по индексу. Итак, вопрос сводится к следующему: в конкретном случае использования вашего приложения ХОТИТЕ ли вы поддерживать такое использование (предположительно, возвращая только что созданную коллекцию!) Для удобства вызывающего абонента - или вам нужна скорость для простого случая, когда все вызывающей стороне необходимо выполнить цикл по коллекции, и вы можете безопасно вернуть ссылку на реальную базовую коллекцию, не опасаясь, что это приведет к ее ошибочным изменениям и т. д.?

Только вы можете ответить на этот вопрос, и только хорошо понимая, что ваши вызывающие абоненты захотят делать с возвращаемым значением и насколько важна здесь производительность (насколько велики коллекции, которые вы будете копировать, насколько вероятно, что это будет узким местом, и т.д).

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

В случае с возвращаемым значением сложнее. Чего ожидает ваш собеседник? Если вы вернете IEnumerable, он априори не будет знать, что может сделать из него IList. Но если вы вернете IList, он будет знать, что может перебирать его. Итак, вы должны принять во внимание, что ваш вызывающий абонент собирается делать с данными. Функциональные возможности, которые требуются / ожидаются от вашего вызывающего абонента, - это то, что должно регулировать при принятии решения о том, что возвращать.

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

IEnumerable неэффективен для подсчета элементов

Если коллекция предназначена только для чтения или модификация коллекции контролируется Parent, то возвращать IList только для Count - не лучшая идея.

В Linq есть Count() метод расширения на IEnumerable<T>, который внутри CLR будет сокращать до .Count, если базовый тип имеет IList, поэтому разница в производительности незначительна.

Как правило, я считаю (мнение), что лучше возвращать IEnumerable, где это возможно, если вам нужно делать дополнения, затем добавьте эти методы в родительский класс, в противном случае потребитель затем управляет коллекцией в модели, что нарушает принципы, например. manufacturer.Models.Add(model) нарушает закон Деметры. Конечно, это всего лишь рекомендации, а не жесткие и быстрые правила, но до тех пор, пока вы полностью не поймете их применимость, лучше слепо следовать, чем не следовать вовсе.

public interface IManufacturer 
{
     IEnumerable<Model> Models {get;}
     void AddModel(Model model);
}

(Примечание: при использовании nNHibernate вам может потребоваться сопоставление с частным IList с использованием разных аксессоров.)

TL; DR; - резюме

• Если вы разрабатываете собственное программное обеспечение, используйте определенный тип (например, List) для возвращаемых значений и наиболее общий тип для входных параметров даже в случае коллекций.
• Если метод является частью общедоступного API распространяемой библиотеки, используйте интерфейсы вместо конкретных типов коллекций, чтобы ввести как возвращаемые значения, так и входные параметры.
• Если метод возвращает коллекцию, доступную только для чтения, покажите это, используя IReadOnlyList или IReadOnlyCollection в качестве типа возвращаемого значения.

Дополнительно

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

Если вы не учитываете в своем внешнем коде, всегда лучше вернуть IEnumerable, потому что позже вы можете изменить свою реализацию (без воздействия внешнего кода), например, для логики yield итератора и сохранить ресурсы памяти ( кстати очень хорошая языковая функция).

Однако, если вам нужно подсчитать количество элементов, не забывайте, что между IEnumerable и IList есть еще один уровень - ICollection.

Возможно, я немного ошибаюсь, потому что пока никто этого не предлагал, но почему бы вам не вернуть (I)Collection<T>?

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

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

IEnumerable неэффективен для подсчета элементов или получения определенного элемента в коллекции.

List - это коллекция, которая идеально подходит для поиска определенных элементов, простого добавления или удаления элементов.

Обычно я стараюсь использовать List, где это возможно, так как это дает мне больше гибкости.

Используйте List<FooBar> getRecentItems() вместо IList<FooBar> GetRecentItems()

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

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

Помните, что перемещение UP к коллекции из IEnumerable в интерфейсе будет работать, переход к IEnumerable из коллекции нарушит существующий код.

Если все эти мнения кажутся противоречивыми, это потому, что решение является субъективным.