Возврат «IList» против «ICollection» против «Collection»

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

Я имею в виду коллекции IList, ICollectionи Collection.

Всегда ли предпочтительнее возвращать один из этих типов по сравнению с другими или это зависит от конкретной ситуации?

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

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

ICollection<T>представляет собой интерфейс , который предоставляет коллекцию семантики , такие как Add(), Remove(), и Count.

Collection<T>это конкретная реализация ICollection<T>интерфейса.

IList<T>по сути, имеет ICollection<T>доступ в произвольном порядке.

В этом случае вы должны решить, требуется ли для ваших результатов семантика списка, такая как индексирование на основе порядка (затем используйте IList<T>), или вам просто нужно вернуть неупорядоченный «мешок» результатов (затем использовать ICollection<T>).

Основное различие между IList<T>и ICollection<T>заключается в том, что IList<T>вы можете получать доступ к элементам через индекс. IList<T>описывает типы, подобные массивам. ICollection<T>Доступ к элементам в объекте можно получить только через перечисление. Оба позволяют вставлять и удалять элементы.

Если вам нужно только перечислить коллекцию, IEnumerable<T>это предпочтительнее. Он имеет два преимущества перед остальными:

1. Он запрещает вносить изменения в коллекцию (но не в элементы, если они ссылочного типа).

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

Collection<T>- это базовый класс, который в основном полезен разработчикам коллекций. Если вы предоставите его в интерфейсах (API), многие полезные коллекции, не являющиеся производными от него, будут исключены.

Одним из недостатков IList<T>является то, что массивы реализуют это, но не позволяют добавлять или удалять элементы (т.е. вы не можете изменять длину массива). Если вы вызываете IList<T>.Add(item)массив, будет выброшено исключение . Ситуация несколько смягчена, поскольку IList<T>есть логическое свойство, IsReadOnlyкоторое вы можете проверить, прежде чем пытаться это сделать. Но на мой взгляд, это по-прежнему недостаток дизайна библиотеки . Поэтому использую List<T>напрямую, когда требуется возможность добавлять или удалять элементы.

IList<T>является базовым интерфейсом для всех общих списков. Поскольку это упорядоченная коллекция, реализация может выбрать порядок, начиная от отсортированного до порядка вставки. Кроме того, Ilistесть свойство Item, которое позволяет методам читать и редактировать записи в списке на основе их индекса. Это позволяет вставлять, удалять значение в / из списка по индексу позиции.

Кроме того IList<T> : ICollection<T>, ICollection<T>здесь доступны для реализации все методы из .

ICollection<T>является базовым интерфейсом для всех общих коллекций. Он определяет размер, счетчики и методы синхронизации. Вы можете добавить или удалить элемент в коллекцию, но вы не можете выбрать, в какой позиции это происходит из-за отсутствия свойства index.

Collection<T>обеспечивает реализацию IList<T>, IListи IReadOnlyList<T>.

Если вы используете более узкий тип интерфейса, например ICollection<T>вместо IList<T>, вы защитите свой код от критических изменений. Если вы используете более широкий тип интерфейса, например IList<T>, вы больше рискуете нарушить изменения кода.

Цитата из источника ,

ICollection, ICollection<T>: Вы хотите изменить коллекцию или заботитесь о ее размере. IList, IList<T>: Вы хотите изменить коллекцию и заботитесь о порядке и / или расположении элементов в коллекции.

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

И, если вы не читали его раньше, Брэд Абрамс и Кшиштоф Квалина написали отличную книгу под названием «Рекомендации по разработке фреймворка: соглашения, идиомы и шаблоны для многоразовых библиотек .NET» (вы можете скачать дайджест отсюда ).

Из этого вопроса вытекает несколько тем:

• интерфейсы против классов
• какой конкретный класс из нескольких одинаковых классов, коллекции, списка, массива?
• Общие классы по сравнению с коллекциями подэлементов ("дженериков")

Вы можете выделить, что это объектно-ориентированный API

интерфейсы против классов

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

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

Вы увидите много интерфейсов в API, но не торопитесь, если он вам не нужен.

Со временем вы узнаете, как применять интерфейсы к вашему коду.

какой конкретный класс из нескольких одинаковых классов, коллекции, списка, массива?

В C # (dotnet) есть несколько классов, которые можно менять местами. Как уже упоминалось, если вам нужно что-то из более конкретного класса, например «CanBeSortedClass», сделайте это явным образом в своем API.

Действительно ли вашему пользователю API нужно знать, что ваш класс можно отсортировать, или применить какой-то формат к элементам? Затем используйте CanBeSortedClass или ElementsCanBePaintedClass, в противном случае используйте GenericBrandClass.

В противном случае используйте более общий класс.

Общие классы коллекций по сравнению с коллекциями подэлементов ("обобщенных")

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

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

Потребуется ли вашему пользователю API очень специфический тип, одинаковый для всех элементов?

Используйте что-нибудь вроде List<WashingtonApple>.

Потребуется ли вашему пользователю API несколько связанных типов?

Expose List<Fruit>для API, и использовать List<Orange> List<Banana>, List<Strawberry>внутри, где Orange, Bananaи Strawberryявляются потомками Fruit.

Потребуется ли вашему пользователю API общая коллекция типов?

Используйте List, где находятся все предметы object.

Приветствия.