Повернення "IList" vs "ICollection" vs "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>є базовим інтерфейсом для всіх загальних колекцій. Він визначає розмір, нумератори та методи синхронізації. Ви можете додати або вилучити елемент у колекцію, але ви не можете вибрати, в якій позиції це відбувається через відсутність властивості індексу.

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" (ви можете завантажити дайджест тут ).

З цього питання випливають деякі теми:

• інтерфейси та класи
• який клас, з декількох однакових класів, колекція, список, масив?
• Загальні класи по колекціях субітемів ("generics")

Ви можете підкреслити, що це об’єктно-орієнтований API

інтерфейси та класи

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

І, нарешті, зробити поганий дизайн інтерфейсу замість хорошого дизайну класу, який, до речі, з часом може бути перенесений на хороший дизайн інтерфейсу ...

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

Ви з часом навчитеся застосовувати інтерфейси до свого коду.

який клас, з декількох однакових класів, колекція, список, масив?

У c # (dotnet) є кілька класів, які можна змінювати. Як уже зазначалося, якщо вам потрібно щось із більш конкретного класу, наприклад, "CanBeSortedClass", то зробіть це явним у вашому API.

Чи дійсно вашому користувачеві API потрібно знати, що ваш клас можна сортувати або застосувати до елементів певний формат? Потім використовуйте "CanBeSortedClass" або "ElementsCanBePaintedClass", інакше використовуйте "GenericBrandClass".

В іншому випадку використовуйте більш загальний клас.

Загальні класи колекцій проти колекцій підтеми ("generics")

Ви виявите, що є класи, які містять інші елементи, і ви можете вказати, що всі елементи повинні бути певного типу.

Загальні колекції - це ті класи, які ви можете використовувати одну і ту ж колекцію для декількох програм коду, не створюючи нової колекції, для кожного нового типу підпункту, наприклад: Збірник .

Чи потрібен вашому користувачеві API дуже специфічний тип, однаковий для всіх елементів?

Використовуйте щось подібне List<WashingtonApple>.

Чи буде потрібно вашому користувачеві API кілька пов’язаних типів?

Expose List<Fruit>для API, і використовувати List<Orange> List<Banana>, List<Strawberry>всередині, де Orange, Bananaі Strawberryє нащадками Fruit.

Чи потребує ваш користувач API колекцію загального типу?

Використовуйте List, де всі предмети object.

Ура.