Колекція <T> порівняно зі списком <T>, що слід використовувати у своїх інтерфейсах?

Код виглядає нижче:

namespace Test
{
    public interface IMyClass
    {
        List<IMyClass> GetList();
    }

    public class MyClass : IMyClass
    {
        public List<IMyClass> GetList()
        {
            return new List<IMyClass>();
        }
    }
}

Коли я запускаю аналіз коду, я отримую наступну рекомендацію.

Попередження 3 CA1002: Microsoft.Design: Змініть "Список" у "IMyClass.GetList ()", щоб використовувати колекцію, ReadOnlyCollection або KeyedCollection

Як я маю це виправити і яка тут хороша практика?

Щоб відповісти на частину питання "чому", чому ні List<T>, причини - це стійкість до майбутнього та простота API.

Майбутнє стійкість

List<T>не розроблено так, щоб було легко розширюється шляхом його підкласифікації; він розроблений так, щоб бути швидким для внутрішніх реалізацій. Ви помітите, що методи на ньому не є віртуальними, тому їх не можна перекрити, і немає жодних гачків для його Add/ Insert/ Removeоперацій.

Це означає, що якщо вам потрібно буде в майбутньому змінити поведінку колекції (наприклад, відхилити нульові об'єкти, які люди намагаються додати, або виконати додаткову роботу, коли це відбувається, наприклад, оновлення стану вашого класу), то вам потрібно змінити тип колекції ви повертаєтесь до одного підкласу, який буде порушувати зміну інтерфейсу (звичайно, зміна семантики таких речей, як, наприклад, не дозволяючи null, також може бути зміною інтерфейсу, але таких речей, як оновлення стану вашого внутрішнього класу, не буде).

Отже, повертаючи або клас, який можна легко підкласифікувати, Collection<T>або інтерфейс, наприклад IList<T>, ICollection<T>або IEnumerable<T>ви можете змінити внутрішню реалізацію на інший тип колекції, щоб задовольнити ваші потреби, не порушуючи код споживачів, оскільки його все одно можна повернути як тип, якого вони очікують.

Простота API

List<T>містить багато корисних операцій , таких як BinarySearch, Sortі так далі. Однак якщо це колекція, яку ви виставляєте, то, ймовірно, ви керуєте семантикою списку, а не споживачами. Тож як ваш клас всередині може потребувати цих операцій, споживачі вашого класу хотіли б (або навіть повинні) їх викликати.

Таким чином, пропонуючи простіший клас колекції або інтерфейс, ви зменшуєте кількість членів, які бачать користувачі вашого API, і полегшуєте їх використання.

Я особисто заявив би про це, щоб повернути інтерфейс, а не конкретну колекцію. Якщо ви дійсно хочете отримати доступ до списку, використовуйте IList<T>. В іншому випадку розглянемо ICollection<T>і IEnumerable<T>.

Я не думаю, що ніхто ще не відповів на частину "чому" ... так ось що. Причина, чому "ви" повинні "використовувати Collection<T>замість а", List<T>полягає в тому, що якщо ви виставляєте List<T>, то кожен, хто отримує доступ до вашого об'єкта, може змінювати елементи в списку. Тоді якCollection<T> як передбачається вказувати, що ви робите власні методи "Додати", "Видалити" тощо.

Вам, мабуть, не потрібно турбуватися про це, тому що ви, мабуть, кодуєте інтерфейс лише для себе (а може, і декількох колег). Ось ще один приклад, який може мати сенс.

Якщо у вас є загальнодоступний масив, наприклад:

public int[] MyIntegers { get; }

Ви б могли подумати, що тому, що існує лише "отримати" аксесуар, який ніхто не може зіпсувати зі значеннями, але це неправда. Будь-хто може змінити значення всередині просто так:

someObject.MyIngegers[3] = 12345;

Особисто я б просто використовував List<T>у більшості випадків. Але якщо ви проектуєте бібліотеку класів, яку збираєтеся видавати випадковим розробникам, і вам потрібно покластися на стан об’єктів ... тоді ви захочете створити власну колекцію та заблокувати її звідти: )

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

Недобра практика дозволяти іншим об'єктам (або людям) безпосередньо змінювати стан ваших об'єктів. Подумайте про власників / сеттерів.

Колекція -> Для звичайної колекції
ReadOnlyCollection -> Для колекцій, які не слід змінювати
KeyedCollection -> Коли вам потрібні словники.

Як це виправити, залежить від того, що ви хочете робити у вашому класі та від призначення методу GetList (). Чи можете ви докладно?

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

Щось додати, хоча минуло давно, як це просили.

Якщо тип списку походить від List<T>замість цього Collection<T>, ви не можете реалізувати захищені віртуальні методи, що Collection<T>реалізуються. Це означає, що отриманий тип не може відповісти, якщо в списку внесені будь-які зміни. Це тому, що List<T>передбачає, що ви знаєте, коли ви додаєте або видаляєте елементи. Можливість відповідати на сповіщення є великою вагою, а значить List<T>, не пропонує.

У випадках, коли зовнішній код має доступ до вашої колекції, ви можете не контролювати, коли елемент додається чи видаляється. Тому Collection<T>надає спосіб дізнатися, коли ваш список був змінений.

Я не бачу жодної проблеми з поверненням чогось подібного

this.InternalData.Filter(crteria).ToList();

Якщо я повернув відключену копію внутрішніх даних або відокремлений результат запиту даних - я можу сміливо повертатися, List<TItem>не піддаючи жодної деталі реалізації, і дозволяю використовувати повернені дані зручним способом.

Але це залежить від того, якого типу споживача я очікую - якщо це щось на зразок сітки даних, я вважаю за краще повернути, IEnumerable<TItem> який у більшості випадків буде скопійованим списком елементів :)

Ну а клас колекції - це просто клас обгортки навколо інших колекцій, щоб приховати деталі їх реалізації та інші функції. Я вважаю, що це має щось спільне з властивістю, що приховує шаблон кодування в об'єктно-орієнтованих мовах.

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

//using System.Collections.ObjectModel;

Collection<MyClass> myCollection = new Collection<MyClass>(myList);