Я должен возвратить массив или набор от функции?

Массив вреден, но ICollection<T> также вредно.

ICollection<T> не может гарантировать, что объект будет неизменен.

Моя рекомендация состоит в том, чтобы обернуть объект возврата с ReadOnlyCollection<T>

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

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

Что когда-либо делает Ваш код более читаемым, удобным в сопровождении и легче для ВАС. Я использовал бы простой массив, более простой == лучше большую часть времени. Хотя я действительно должен видеть контекст для предоставления правильного ответа.

Используйте дженерики. Легче взаимодействовать с другими классами наборов, и система типов больше может помочь Вам с потенциальными ошибками.

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

Всегда возвращайте интерфейсный тип, который представляет самую большую сумму функциональности вызывающей стороне. Таким образом в Вашем случае ICollection<YourType> должен использоваться.

Что-то интересное для замечания - то, что разработчики BCL на самом деле поняли превратно, это в некотором месте платформы.NET - видит это сообщение в блоге Eric Lippert для той истории.

Почему не IList<MyType>?

Это поддерживает прямую индексацию, которая является признаком для массива, не удаляя возможность возвратиться List<MyType> однажды. Если Вы хотите подавить эту функцию, Вы, вероятно, хотите возвратиться IEnumerable<MyType>.

Если набор, который возвращается, только для чтения, означая, что Вы никогда не хотите, чтобы элементы к в наборе были изменены, затем использовали IEnumerable<T>. Это - самое основное представление последовательности только для чтения неизменных (по крайней мере, с точки зрения самого перечисления) элементы.

, Если Вы хотите, чтобы это было автономным набором, который может быть изменен, затем используйте ICollection<T> или IList<T>.

, Например, если Вы хотели возвратить результаты поиска определенного набора файлов, затем возвращаются IEnumerable<FileInfo>.

Однако, если бы Вы хотели представить файлы в каталоге, однако, Вы представили бы IList/ICollection<FileInfo>, поскольку он имеет смысл, что Вы хотели бы возможно изменить содержание набора.

Почему не List<T>?

Из сообщения Eric Lippert, упомянутого другими, я думал, что выделю это:

, Если мне нужна последовательность использование I’ll IEnumerable<T>, если мне нужно отображение от непрерывных чисел до данных, I’ll используют List<T>, если мне нужно отображение через произвольные данные, I’ll используют Dictionary<K,V>, если мне нужен набор, I’ll используют HashSet<T>. Мне просто don’t нужны массивы для чего-либо, таким образом, я почти никогда не использую их. Они don’t решают проблему, которую я имею лучше, чем другие инструменты в моем распоряжении.

return ICollection<type>

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

Вернуть IEnumerable , используя yield return .

Это зависит от того, что вы планируете делать с возвращаемой коллекцией. Если вы просто выполняете итерацию или хотите, чтобы пользователь выполнял итерацию, я согласен с @Daniel, верните IEnumerable . Однако, если вы действительно хотите разрешить операции на основе списка, я бы вернул IList .

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

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

Это наименее самонадеянный подход, который вы, API разработчик, может взять. Не вам решать, как потребитель вашей функции будет использовать то, что они вам отправят, поэтому вы должны вернуть IList в этом случае, чтобы дать им наибольшую гибкость. Также по этой же причине вы никогда не сможете предположить, что знаете, какой тип параметра вам отправит потребитель. Если вам нужно только повторить последовательность, отправленную вам в качестве параметра, сделайте параметр IEnumerable , а не List .

EDIT (монооксид) : Поскольку не похоже, что вопрос будет закрыт, я просто хочу добавить ссылку из другого вопроса по этому поводу: Почему массивы вредны

Хороший совет, который я часто слышал, таков:

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

С точки зрения разработки вашего API, я бы посоветовал вам возвращать интерфейс, а не конкретный тип.

Взяв ваш примерный метод, я бы переписал его как следует:

public IList<object> Foo() 
{
    List<object> retList = new List<object>();
    // Blah, blah, [snip]
    return retList;
}

Ключ в том, что ваш внутренний вариант реализации - использование списка - не раскрывается вызывающей стороне, но вы возвращаете соответствующий интерфейс.

Собственные рекомендации Microsoft по разработке фреймворков не рекомендуют возвращать определенные типы, отдавая предпочтение интерфейсам. (Извините, мне не удалось найти для этого ссылку)

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

Снова возьмем ваш примерный метод:

public IList<object> Foo(IEnumerable<object> bar) 
{
    List<object> retList = new List<object>();
    // Blah, blah, [snip]
    return retList;
}