Плануючи свої програми, я часто починаю такий ланцюжок думок:

Футбольна команда - це лише список футболістів. Тому я мушу представляти це:

var football_team = new List<FootballPlayer>();

Упорядкованість цього списку представляє порядок, у якому гравці занесені до списку.

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

Тож я думаю:

Гаразд, футбольна команда подібно до списку гравців, але крім того, вона має назву (а string) та загальну кількість балів (an int). .NET не пропонує класу для зберігання футбольних команд, тому я зроблю свій клас. Найбільш схожа і відповідна існуюча структура List<FootballPlayer>, тому я успадкую її:

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

Але виявляється, що керівництво говорить, що не слід успадковуватиList<T> . Мене цією настановою я глибоко плутаю в двох аспектах.

Чому ні?

Мабуть, Listце якось оптимізовано для продуктивності . Як так? Які проблеми з працездатністю я викличу, якщо продовжу List? Що саме зламається?

Ще одна причина, яку я бачив, - це те, що Listнадається корпорацією Майкрософт, і я не маю контролю над цим, тому я не можу її змінити пізніше, після викриття "публічного API" . Але я намагаюся це зрозуміти. Що таке загальнодоступний API і чому я повинен турбуватися? Якщо мій поточний проект не має і, ймовірно, ніколи не матиме цей публічний API, чи можу я сміливо ігнорувати цю інструкцію? Якщо я успадковую List і виявляється, що мені потрібен публічний API, які труднощі виникнуть у мене?

Чому це навіть важливо? Список - це список. Що може змінитися? Що я міг би хотіти змінити?

І нарешті, якщо Microsoft не хотіла, щоб я успадкував List, чому вони не склали клас sealed?

Що ще я повинен використовувати?

Мабуть, для користувацьких колекцій Microsoft запропонувала Collectionклас, який слід розширити замість List. Але цей клас дуже голий і не має багато корисних речей, наприкладAddRange , наприклад. Відповідь jvitor83 забезпечує обґрунтування продуктивності саме для цього методу, але як повільний AddRangeне кращий, ніж ні AddRange?

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

Я бачив такі пропозиції, як реалізація IList. Просто ні. Це десятки рядків кодового коду, які мені нічого не приносять.

Нарешті, деякі пропонують обговорити Listщось:

class FootballTeam 
{ 
    public List<FootballPlayer> Players; 
}

З цим є дві проблеми:

1. Це робить мій код непотрібним багатослівним. Я повинен зараз зателефонувати, my_team.Players.Countа не просто my_team.Count. На щастя, за допомогою C # я можу визначити індексатори, щоб зробити індексацію прозорою та передати всі внутрішні методи List... Але це дуже багато коду! Що я отримую за всю цю роботу?

2. Це просто не має сенсу. Футбольна команда не має "списку гравців". Це є список гравців. Ви не кажете, що "Джон МакФоотбаллер приєднався до гравців SomeTeam". Ви кажете "Джон приєднався до SomeTeam". Ви не додаєте листа до "символів рядка", ви додаєте лист до рядка. Ви не додаєте книгу до книг бібліотеки, ви додаєте книгу до бібліотеки.

Я усвідомлюю, що те, що відбувається "під кришкою", можна сказати як "додавання X до внутрішнього списку Y", але це здається дуже протиінтуїтивним способом мислення про світ.

Моє запитання (узагальнене)

Що таке правильний C # спосіб представлення структури даних, які, «логічно» (тобто, «для людського розуму») є просто listз thingsз декількома прибамбасами?

Чи успадковування List<T>завжди від неприйнятного? Коли це прийнятно? Чому / чому ні? Що повинен врахувати програміст, приймаючи рішення про спадщину List<T>чи ні?

Тут є кілька хороших відповідей. Я б до них додав наступні моменти.

Який правильний спосіб C # представляє структуру даних, яка "логічно" (тобто "людському розуму") - лише список речей з кількома дзвіночками?

Попросіть будь-яких десяти людей, які не є комп'ютерними програмістами, які знайомі з футболом, заповнити бланк:

Футбольна команда є особливим видом _____

Чи хто - небудь , скажімо «список футболістів з декількома прибамбасами», або ж вони всі говорять «спортивна команда» або «клуб» або «організація»? Ваше уявлення про те, що футбольна команда є певним видом переліків гравців, лежить у вашому людському розумі та лише у вашому людському розумі.

List<T>є механізмом . Футбольна команда - це бізнес-об’єкт - тобто об’єкт, який представляє якусь концепцію, що знаходиться в бізнес-області програми. Не змішуйте їх! Футбольна команда - це свого роду команда; у нього є реєстр, реєстр - це список гравців . Список не є певним видом гравців . Реєстр являє список гравців. Тож зробіть властивість, яку називають Rostera List<Player>. І зробіть це, ReadOnlyList<Player>поки ви на ньому, якщо не вірите, що кожен, хто знає про футбольну команду, може видалити гравців із списку.

Чи успадковування List<T>завжди від неприйнятного?

Неприйнятний для кого? Я? Ні.

Коли це прийнятно?

Коли ви будуєте механізм, який розширює List<T>механізм .

Що повинен врахувати програміст, приймаючи рішення про спадщину List<T>чи ні?

Я будую механізм чи бізнес-об’єкт ?

Але це багато коду! Що я отримую за всю цю роботу?

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

ОНОВЛЕННЯ

Я ще трохи подумав, і є ще одна причина не моделювати футбольну команду як список гравців. Насправді може бути поганою ідеєю моделювати футбольну команду, яка також має список гравців. Проблема з командою, як / з переліком гравців, полягає в тому, що у вас є моментальний знімок команди за момент часу . Я не знаю, що стосується вашого бізнесу для цього класу, але якби у мене був клас, який представляв футбольну команду, я хотів би поставити йому запитання на кшталт "скільки гравців Seahawks пропустили ігри через травму між 2003 та 2013 роками?" або "У якого гравця Денвера, який раніше грав за іншу команду, найбільше за рік збільшилося зростання дворів?" або " Чи цього року Свині пройшли всю дорогу? "

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

Нічого собі, у вашому дописі є цілий ряд питань та питань. Більшість міркувань, які ви отримуєте від Майкрософт, є саме суттєвими. Почнемо з усього, що стосуєтьсяList<T>

• List<T> є оптимізованим. Основне його використання - використовувати як приватний член об'єкта.
• Microsoft не має запечатати його , тому що іноді ви можете створити клас , який має ім'я дружнє: class MyList<T, TX> : List<CustomObject<T, Something<TX>> { ... }. Зараз це так просто, як зробити var list = new MyList<int, string>();.
• CA1002: Не виставляйте загальних списків . В основному, навіть якщо ви плануєте використовувати цей додаток як єдиний розробник, варто розробитись з хорошими методами кодування, щоб вони прищепилися вам і другого характеру. Вам все ще дозволяється виставити цей список як такий, IList<T>якщо вам потрібен будь-який споживач, який має індексований список. Це дозволить вам змінити реалізацію в класі пізніше.
• Microsoft зробила Collection<T>дуже загальне, тому що це загальне поняття ... назва говорить усе; це просто колекція. Є більш точні версії , такі як SortedCollection<T>, ObservableCollection<T>, ReadOnlyCollection<T>і т.д. , кожен з яких реалізують , IList<T>але НЕ List<T> .
• Collection<T>дозволяє членам (тобто додавати, видаляти тощо), щоб перекрити, тому що вони віртуальні. List<T>не.
• Остання частина вашого запитання - це місце. Футбольна команда - це не просто перелік гравців, тому це повинен бути клас, який містить цей список гравців. Подумайте про склад проти успадкування . Футбольна команда має список гравців (реєстр), це не список гравців.

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

public class FootballTeam
{
    // Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    // Yes. I used LINQ here. This is so I don't have to worry about
    // _roster.Length vs _roster.Count vs anything else.
    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    // Any additional members you want to expose/wrap.
}

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal;
}

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

У всякому разі, цей код (з моєї відповіді)

public class FootballTeam
{
    // A team's name
    public string TeamName; 

    // Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    // Any additional members you want to expose/wrap.
}

Значить: це футбольна команда, яка має керівництво, гравців, адміністраторів тощо.

Ось як представлена ​​ваша логіка на фотографіях ...

Це класичний приклад композиції проти спадкування .

У цьому конкретному випадку:

Команда - це список гравців з додатковою поведінкою

або

Чи є власна команда об'єктом, який містить список гравців.

Розширюючи Список, ви обмежуєте себе кількома способами:

1. Ви не можете обмежувати доступ (наприклад, зупиняти людей, що змінюють список). Ви отримуєте всі методи Списку, чи потрібно вам / хотіти їх усіх, чи ні.

2. Що станеться, якщо ви хочете також мати списки інших речей. Наприклад, команди мають тренерів, менеджерів, вболівальників, обладнання тощо. Деякі з них цілком можуть бути списками.

3. Ви обмежуєте свої варіанти спадкування. Наприклад, ви можете створити загальний об'єкт Team, а потім мати BaseballTeam, FootballTeam тощо, які успадковують це. Щоб успадкувати зі списку вам потрібно зробити спадщину від Team, але це означає, що всі різні типи команди змушені мати однакову реалізацію цього списку.

Композиція - включаючи об’єкт, що надає потрібну вам поведінку всередині вашого об'єкта.

Успадкування - ваш об'єкт стає екземпляром об'єкта, який має потрібну вам поведінку.

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

Як усі зазначали, команда гравців - це не список гравців. Ця помилка робиться багатьма людьми скрізь, можливо, на різних рівнях знань. Часто проблема є тонкою, а іноді і дуже грубою, як у цьому випадку. Такі конструкції погані, оскільки вони порушують Принцип заміни Ліскова . В Інтернеті є багато хороших статей, що пояснюють це поняття, наприклад, http://en.wikipedia.org/wiki/Liskov_substitution_principle

Підсумовуючи, є два правила, які слід зберігати у відносинах батько / дитина серед класів:

• Дитина повинна вимагати не менше характеристик, ніж те, що повністю визначає Батька.
• Батько не повинен мати ніяких характеристик, крім того, що повністю визначає Дитину.

Іншими словами, Батько - це необхідне визначення дитини, а дитина - достатнє визначення Батька.

Ось спосіб продумати рішення та застосувати вищезазначений принцип, який повинен допомогти уникнути такої помилки. Слід перевірити гіпотезу, перевіривши, чи всі операції батьківського класу дійсні для похідного класу як структурно, так і семантично.

• Чи є футбольна команда переліком футболістів? (Чи всі властивості списку застосовуються до команди в одному значенні)
  • Чи колектив - це сукупність однорідних утворень? Так, команда - це колекція Гравців
  • Чи порядок включення гравців описує стан команди та чи гарантує команда збереження послідовності, якщо явно не змінено? Ні, і Ні
  • Очікується, що гравці будуть включені / відкинуті з урахуванням своєї послідовної позиції в команді? Ні

Як бачите, лише перша характеристика списку застосовна до команди. Отже, команда - це не список. У списку буде деталізована інформація про те, як ви керуєте своєю командою, тому її слід використовувати лише для зберігання об’єктів гравця та маніпулювання методами класу Team.

На цьому етапі я хотів би зазначити, що, на мій погляд, командний клас навіть не повинен реалізовуватися за допомогою Списку; його слід реалізувати, використовуючи структуру даних Set (наприклад, HashSet) у більшості випадків.

Що робити, якщо у FootballTeamрезервної команди є разом із основною командою?

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
}

Як би ви це моделювали?

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

Відносини явно мають, а не є .

або RetiredPlayers?

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
    List<FootballPlayer> RetiredPlayers { get; set; }
}

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

Чи SomethingCollectionмає сенс ваш сенс? Тільки зробіть це , якщо ваш тип є колекція Something.

У випадку FootballTeamце не правильно звучить. А Team- це більше, ніж а Collection. А Teamможе мати тренерів, тренерів тощо, як вказували інші відповіді.

FootballCollectionзвучить як колекція футболів або, можливо, колекція футбольної атрибутики. TeamCollection, колекція команд.

FootballPlayerCollectionзвучить як колекція гравців, яка була б дійсною назвою для класу, який успадковує, List<FootballPlayer>якщо ви дійсно хотіли цього зробити.

Дійсно List<FootballPlayer>- це ідеально хороший тип для вирішення. Можливо, IList<FootballPlayer>якщо ви повертаєте його з методу.

Підводячи підсумок

Запитайте себе

1. Є ? або має ?XY XY

2. Чи означають назви моїх класів, якими вони є?

Дизайн> Впровадження

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

Об'єкт - це сукупність даних та поведінки.

Тож вашими першими питаннями мають бути:

• Які дані містить цей об’єкт у створеній мені моделі?
• Яку поведінку проявляє цей об’єкт у цій моделі?
• Як це може змінитися в майбутньому?

Майте на увазі, що успадкування передбачає "isa" (є) відносини, тоді як склад означає, що "має" (hasa) відносини. Виберіть правильний для себе ситуацію на ваш погляд, маючи на увазі, де все може йти в міру розвитку вашої програми.

Подумайте про інтерфейси, перш ніж подумати про конкретні типи, оскільки деяким людям легше перевести свій мозок у «дизайн-режим» таким чином.

Це не те, що кожен свідомо робить на цьому рівні щоденне кодування. Але якщо ви роздумуєте над такою темою, ви ступаєте в дизайнерських водах. Усвідомлення цього може бути визвольним.

Розглянемо особливості дизайну

Погляньте на Список <T> та IList <T> на MSDN або Visual Studio. Подивіться, яким методам та властивостям вони піддаються. Чи всі ці методи схожі на те, що хтось хотів би зробити з FootballTeam на ваш погляд?

Чи має для вас сенс footballTeam.Reverse ()? Чи виглядає footballTeam.ConvertAll <TOutput> () як щось, що ви хочете?

Це не хитрі питання; відповідь справді може бути "так". Якщо ви реалізуєте / успадкуєте Список <Player> або IList <Player>, ви затримаєтесь з ними; якщо це ідеально для вашої моделі, зробіть це.

Якщо ви вирішили так, це має сенс, і ви хочете, щоб ваш об'єкт піддавався лікуванню як колекція / список гравців (поведінка), і, отже, ви хочете реалізувати ICollection або IList, всіма способами це зробіть. Умовно:

class FootballTeam : ... ICollection<Player>
{
    ...
}

Якщо ви хочете, щоб ваш об'єкт містив колекцію / список плеєрів (даних), і тому ви хочете, щоб колекція або список були власністю або членом, будь ласка, зробіть це. Умовно:

class FootballTeam ...
{
    public ICollection<Player> Players { get { ... } }
}

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

Вам може здатися, що жоден із цих інтерфейсів взагалі не корисний у вашій моделі. Це менш вірогідно (IEnumerable <T> корисний у багатьох ситуаціях), але все ж можливо.

Кожен, хто намагається сказати вам, що один із них категорично і остаточно неправильний у кожному випадку, є помилковим. Кожен, хто намагається сказати вам, що це категорично і остаточно правильно, у кожному випадку є помилковим.

Переходимо до впровадження

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

Це може бути не великим кроком, і люди часто плутають дизайн та реалізацію, оскільки цілком можливо пропустити все це в голові за секунду-дві і почати друкувати.

Мисленнєвий експеримент

Штучний приклад: як уже згадували інші, команда не завжди є "просто" колекцією гравців. Чи підтримуєте ви збірку результатів матчів для команди? Чи взаємозамінна команда з клубом, за вашою моделлю? Якщо так, і якщо ваша команда - це зібрання гравців, можливо, це також збір персоналу та / або збірка балів. Тоді ви закінчуєте:

class FootballTeam : ... ICollection<Player>, 
                         ICollection<StaffMember>,
                         ICollection<Score>
{
    ....
}

Незважаючи на дизайн, на даний момент у C # ви не зможете реалізувати все це, успадкувавши з List <T> все одно, оскільки C # "лише" підтримує єдине успадкування. (Якщо ви вже пробували це malarky в C ++, ви можете розглянути це хороша річ.) Реалізація однієї колекції з допомогою наслідування і один з допомогою композиції, ймовірно, відчувати себе брудною. А такі властивості, як Count, стають заплутаними для користувачів, якщо явно не реалізувати ILIst <Player> .Count та IList <StaffMember> .Count тощо, і тоді вони просто болючі, а не заплутані. Ви можете бачити, куди це йде; кишкові відчуття, думаючи про цю алею, цілком можуть сказати тобі, що почуваєшся неправильно рухатися в цьому напрямку (і правильно чи неправильно, твої колеги можуть також, якби ти реалізував це таким чином!)

Короткий відповідь (надто пізно)

Настанова щодо не успадкування класів колекції не є специфікою C #, ви знайдете її у багатьох мовах програмування. Мудрість отримана не законом. Однією з причин є те, що на практиці вважається, що композиція часто перемагає спадщину з точки зору зрозумілості, реалізації та ремонтопридатності. З об'єктами реального світу / домену частіше зустріти корисні та послідовні відносини "hasa", ніж корисні та послідовні відносини "isa", якщо ви не заглиблюєтесь в абстрактне, особливо, коли проходить час і точні дані та поведінка об'єктів у коді зміни. Це не повинно змусити вас завжди виключати спадкування з колекційних класів; але це може бути сугестивним.

Перш за все, це стосується юзабіліті. Якщо ви користуєтеся успадкуванням, Teamклас викриє поведінку (методи), призначені виключно для маніпулювання об'єктом. Наприклад, AsReadOnly()або CopyTo(obj)методи не мають сенсу для об'єкта команди. Замість AddRange(items)методу ви, мабуть, хочете більш описовий AddPlayers(players)метод.

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

Як було сказано, композиція - це правильний шлях для цього. Просто реалізуйте список гравців як приватну змінну.

Футбольна команда - це не список футболістів. Футбольна команда складається зі списку футболістів!

Це логічно неправильно:

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

і це правильно:

class FootballTeam 
{ 
    public List<FootballPlayer> players
    public string TeamName; 
    public int RunningTotal 
}

Це залежить від контексту

Коли ви розглядаєте свою команду як список гравців, ви проектуєте "ідею" команди з м'ячем для ніг до одного аспекту: ви зменшуєте "команду" до людей, яких бачите на полі. Ця прогноза правильна лише в певному контексті. В іншому контексті це може бути абсолютно неправильним. Уявіть, що ви хочете стати спонсором команди. Тож вам доведеться поговорити з менеджерами команди. У цьому контексті команда проектується до списку її керівників. І ці два списки зазвичай не сильно перетинаються. Інші контексти - поточний проти колишніх гравців тощо.

Незрозуміла семантика

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

Заняття розширювані

Коли ви використовуєте клас лише з одним членом (наприклад IList activePlayers), ви можете використовувати його ім’я (та додатково його коментар), щоб зрозуміти контекст. Коли є додаткові контексти, ви просто додаєте додатковий член.

Заняття складніші

У деяких випадках може бути зайвим створити додатковий клас. Кожне визначення класу повинно бути завантажено через завантажувач класів і буде кешоване віртуальною машиною. Це коштує вашої продуктивності та пам’яті. Коли у вас дуже специфічний контекст, може бути нормально розглянути футбольну команду як список гравців. Але в цьому випадку вам слід просто використовувати а IList , а не клас, похідний від нього.

Висновок / міркування

Коли у вас дуже специфічний контекст, добре розглядати команду як список гравців. Наприклад, всередині методу можна повністю написати:

IList<Player> footballTeam = ...

Під час використання F # може бути навіть нормально створити абревіатуру типу:

type FootballTeam = IList<Player>

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

Дозвольте переписати ваше запитання. тож ви можете бачити тему з іншого погляду.

Коли мені потрібно представляти футбольну команду, я розумію, що це в основному назва. Як: "Орли"

string team = new string();

Потім я зрозумів, що команди також мають гравців.

Чому я не можу просто розширити тип рядка, щоб він також містив список гравців?

Ваша точка вступу до проблеми є довільною. Спробуйте думати , що це команда має (властивості), а не те , що вона є .

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

Просто тому, що я думаю, що інші відповіді в значній мірі виходять із дотику того, чи є футбольна команда "є-а" List<FootballPlayer>чи "має-а" List<FootballPlayer>, що насправді не відповідає на це запитання як написано.

В основному ОП просить роз'яснити вказівки щодо спадкування від List<T>:

Посібник говорить, що від вас не слід успадковувати List<T>. Чому ні?

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

Що таке загальнодоступний API і чому я повинен піклуватися?

Публічний API - це інтерфейс, який ви піддаєте стороннім програмістам. Подумайте рамковий код. І нагадайте, що вказівки, на які посилаються, - це ".NET Framework Design Guidelines", а не ".NET. Настанови щодо дизайну додатків ". Існує різниця, і, загалом кажучи, - дизайн публічного API набагато суворіший.

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

Досить, так. Можливо, ви хочете розглянути обґрунтування цього питання, щоб зрозуміти, чи стосується воно все-таки до вашої ситуації, але якщо ви не будуєте публічний API, вам не потрібно особливо хвилюватися з приводу проблем API, як-от версії (з них, це підмножина).

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

Чому це навіть важливо? Список - це список. Що може змінитися? Що я міг би хотіти змінити?

Залежить від контексту, але оскільки ми використовуємо FootballTeamяк приклад - уявіть, що ви не можете додати, FootballPlayerякщо це призведе до того, що команда перейде за межі зарплати. Можливий спосіб додати це було б щось на зразок:

 class FootballTeam : List<FootballPlayer> {
     override void Add(FootballPlayer player) {
        if (this.Sum(p => p.Salary) + player.Salary > SALARY_CAP)) {
          throw new InvalidOperationException("Would exceed salary cap!");
        }
     }
 }

Ах ... але ви не можете, override Addтому що це не так virtual(з міркувань ефективності).

Якщо ви користуєтеся програмою (що, в основному, означає, що ви та всі ваші абоненти зібрані разом), тепер ви можете перейти до використання IList<T>та виправлення будь-яких помилок компіляції:

 class FootballTeam : IList<FootballPlayer> {
     private List<FootballPlayer> Players { get; set; }

     override void Add(FootballPlayer player) {
        if (this.Players.Sum(p => p.Salary) + player.Salary > SALARY_CAP)) {
          throw new InvalidOperationException("Would exceed salary cap!");
        }
     }
     /* boiler plate for rest of IList */
 }

але, якщо ви публічно зазнали впливу третьої сторони, ви просто зробили переломну зміну, яка спричинить компіляцію та / або помилки виконання.

TL; DR - рекомендації щодо публічних API. Для приватних API виконайте все, що завгодно.

Чи дозволяє людям сказати

myTeam.subList(3, 5);

взагалі має сенс? Якщо ні, то це не повинен бути список.

Це залежить від поведінки вашого об'єкта "команди". Якщо вона поводиться так само, як колекція, можливо, спочатку представляти її звичайним списком. Тоді ви можете почати помічати, що ви зберігаєте дублюючий код, який повторюється у списку; на даний момент у вас є можливість створити об’єкт FootballTeam, який обгортає список гравців. Клас FootballTeam стає домом для всього коду, який повторюється у списку гравців.

Це робить мій код непотрібним багатослівним. Тепер я повинен зателефонувати my_team.Players.Count замість просто my_team.Count. На щастя, за допомогою C # я можу визначити індексатори, щоб зробити індексацію прозорою та переслати всі методи внутрішнього списку ... Але це дуже багато коду! Що я отримую за всю цю роботу?

Інкапсуляція. Ваші клієнти не повинні знати, що відбувається всередині FootballTeam. Для всіх ваших клієнтів відомо, що це може бути реалізовано, переглянувши список гравців в базі даних. Їм не потрібно знати, і це покращує ваш дизайн.

Це просто не має сенсу. Футбольна команда не має "списку гравців". Це список гравців. Ви не кажете, що "Джон МакФоотбаллер приєднався до гравців SomeTeam". Ви кажете "Джон приєднався до SomeTeam". Ви не додаєте листа до "символів рядка", ви додаєте лист до рядка. Ви не додаєте книгу до книг бібліотеки, ви додаєте книгу до бібліотеки.

Рівно :) ви скажете footballTeam.Add (john), а не footballTeam.List.Add (john). Внутрішній список не буде видимим.

Тут є багато відмінних відповідей, але я хочу торкнутися того, чого я не бачив згаданого: Об'єктно-орієнтований дизайн стосується розширення можливостей об'єктів .

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

Коли ви успадковуєте від List, усі інші об'єкти можуть бачити вас як Список. Вони мають прямий доступ до методів додавання та видалення гравців. І ти втратив контроль; наприклад:

Припустимо, ви хочете розрізнитись, коли гравець піде, знаючи, пішов він у відставку, звільнився чи був звільнений. Ви можете реалізувати RemovePlayerметод, який приймає відповідний вхідний перелік. Однак, успадкувавши від List, ви не змогли б запобігти прямий доступ до Remove, RemoveAllі навіть Clear. Як наслідок, ви насправді знешкодили свій FootballTeamклас.

Додаткові думки щодо інкапсуляції ... Ви викликали таке занепокоєння:

Це робить мій код непотрібним багатослівним. Тепер я повинен зателефонувати my_team.Players.Count замість просто my_team.Count.

Ви маєте рацію, це було б непотрібно, щоб усі клієнти могли використовувати вашу команду. Однак ця проблема є дуже малою порівняно з тим, що ви піддаєтесь List Playersусім і всім, тому вони можуть поспілкуватися з вашою командою без вашої згоди.

Ви продовжуєте говорити:

Це просто не має сенсу. Футбольна команда не має "списку гравців". Це список гравців. Ви не кажете, що "Джон МакФоотбаллер приєднався до гравців SomeTeam". Ви кажете "Джон приєднався до SomeTeam".

Ви помиляєтесь у першому біті: киньте слово «список», і насправді очевидно, що в команди є гравці.
Однак ти вдарив цвях по голові другим. Ви не хочете, щоб клієнти телефонували ateam.Players.Add(...). Ви хочете, щоб вони дзвонили ateam.AddPlayer(...). І ваша реалізація (можливо, серед іншого) дзвонить Players.Add(...)внутрішньо.

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

Який правильний спосіб C # представляє структуру даних ...

Ремебер: "Усі моделі помиляються, але деякі корисні". - Джордж ЕП Коробка

Не існує «правильного шляху», лише корисний.

Виберіть той, який корисний вам та / вашим користувачам. Це воно. Розвивайтесь економічно, не перестарайтеся з інженером. Чим менше коду ви пишете, тим менше коду вам знадобиться налагоджувати. (читайте наступні видання).

- Відредаговано

Моя найкраща відповідь була б ... це залежить. Наслідування зі списку може піддавати клієнтів цього класу методам, які, можливо, не повинні піддаватися впливу, насамперед тому, що FootballTeam виглядає як суб'єкт господарювання.

- Видання 2

Я щиро не пам’ятаю, на що я мав на увазі коментар «не зайвий інженер». Хоча я вважаю, що настрій KISS є гарним посібником, я хочу підкреслити, що успадкування бізнес-класу від List створить більше проблем, ніж це вирішить, через витік абстракції .

З іншого боку, я вважаю, що існує обмежена кількість випадків, коли просто успадкувати зі Списку корисно. Як я писав у попередньому виданні, це залежить. На відповідь у кожному випадку сильно впливають як знання, досвід, так і особисті переваги.

Дякую @kai за те, що допомагає мені точніше думати про відповідь.

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

Що ти робиш? Як і в багатьох справах ... це залежить від контексту. Я б використав посібник, що для того, щоб успадкувати інший клас, справді мають існувати відносини "є". Отже, якщо ви пишете клас під назвою BMW, він може успадкувати від Автомобіля, оскільки BMW справді є автомобілем. Клас Кінь може успадкувати від класу Ссавців, тому що кінь насправді є ссавцем у реальному житті, і будь-яка функція Ссавця повинна відповідати Коні. Але чи можете ви сказати, що команда - це список? З того, що я можу сказати, схоже, що Команда насправді "є" Список. Отже, у цьому випадку я мав би список як змінну члена.

Моя брудна таємниця: Мені все одно, що кажуть люди, і я це роблю. .NET Framework поширюється за допомогою "XxxxCollection" (приклад UIElementCollection на початку моєї голови).

Отже, що перешкоджає мені говорити:

team.Players.ByName("Nicolas")

Коли я вважаю це краще, ніж

team.ByName("Nicolas")

Більше того, мій програвач PlayerCollection може використовуватися іншим класом, наприклад "Club", без будь-якого дублювання коду.

club.Players.ByName("Nicolas")

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

team.Players.ByName("Nicolas") 

або

team.ByName("Nicolas")

Дійсно. У вас є сумніви? Тепер, можливо, вам потрібно пограти з іншими технічними обмеженнями, які заважають вам використовувати List <T> у вашому реальному випадку використання. Але не додайте обмеження, яке не повинно існувати. Якщо Microsoft не документувала, чому це, то це, безумовно, "найкраща практика", яка приходить з нізвідки.

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

Коли кажуть List<T>, що "оптимізовано", я думаю, що вони хочуть означати, що він не має таких функцій, як віртуальні методи, які дорожче. Отже, проблема полягає в тому, що після викриття List<T>у вашому загальнодоступному API ви втрачаєте можливість застосовувати бізнес-правила або налаштовуєте їх функціональність пізніше. Але якщо ви використовуєте цей успадкований клас як внутрішній у межах свого проекту (на відміну від потенційно підданих тисячам ваших клієнтів / партнерів / інших команд як API), можливо, це буде добре, якщо це економить ваш час і це функціонал, який ви хочете дублікат. Перевага наслідування від того List<T>, що ви усуваєте безліч тупих коду обгортки, який просто ніколи не буде налаштований в осяжному майбутньому. Також якщо ви хочете, щоб ваш клас явно мав абсолютно таку саму семантику, якList<T> протягом життя ваших API, тоді також це може бути добре.

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

Хоча я не маю складного порівняння, як це робить більшість цих відповідей, я хотів би поділитися своїм методом вирішення цієї ситуації. Розширюючи IEnumerable<T>, ви можете дозволити своєму Teamкласу підтримувати розширення запитів Linq, не публічно відкриваючи всі методи та властивості List<T>.

class Team : IEnumerable<Player>
{
    private readonly List<Player> playerList;

    public Team()
    {
        playerList = new List<Player>();
    }

    public Enumerator GetEnumerator()
    {
        return playerList.GetEnumerator();
    }

    ...
}

class Player
{
    ...
}

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

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

Для крихітних програм ви також можете обрати іншу, менш сувору мову. Ruby, JavaScript - все, що дозволяє писати менше коду.

Я просто хотів додати, що Бертран Мейєр, винахідник Ейфеля та дизайну за контрактом, отримав би у Teamспадок List<Player>без того, як бив повіку.

У своїй книзі « Об’єктно-орієнтована побудова програмного забезпечення» він обговорює реалізацію системи GUI, де прямокутні вікна можуть мати дочірні вікна. Він просто має у Windowспадок від обох Rectangleі Tree<Window>повторно використовувати його.

Однак C # - це не Ейфелева. Останній підтримує багаторазове успадкування та перейменування функцій . У C #, коли ви підклас, ви успадковуєте і інтерфейс, і імплементацію. Ви можете змінити реалізацію, але умови виклику скопіюються безпосередньо з суперкласу. Однак в Ейфелі ви можете змінювати назви загальнодоступних методів, щоб ви могли перейменовувати Addі Removeв, Hireі Fireв свій Team. Якщо екземпляр Teamповернеться назад до List<Player>, абонент буде використовувати Addі Removeмодифікувати його, але ваші віртуальні методи Hireі Fireбудуть викликані.

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

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

Можливо, поняття ставок PlayerCollection відповідає вашому бажаному підходу?

public class PlayerCollection : Collection<Player> 
{ 
}

І тоді FootballTeam може виглядати так:

public class FootballTeam 
{ 
    public string Name { get; set; }
    public string Location { get; set; }

    public ManagementCollection Management { get; protected set; } = new ManagementCollection();

    public CoachingCollection CoachingCrew { get; protected set; } = new CoachingCollection();

    public PlayerCollection Players { get; protected set; } = new PlayerCollection();
}

Віддавайте перевагу інтерфейсам над класами

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

Спадщина порушує інкапсуляцію

Виведення з класів перерви інкапсуляції :

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

Крім усього іншого, це ускладнює переформатування коду.

Класи - це деталізація впровадження

Заняття - це деталі реалізації, які слід приховувати від інших частин вашого коду. Коротше кажучи System.List, це конкретна реалізація абстрактного типу даних, яка може бути або не підходить зараз і в майбутньому.

Концептуально той факт, що System.Listтип даних називається "список", є трохи червоним оселедцем. A System.List<T>- це мутаційна впорядкована колекція, яка підтримує амортизовані операції O (1) для додавання, вставки та вилучення елементів та O (1) операції для отримання кількості елементів або отримання та встановлення елемента за індексом.

Чим менший інтерфейс, тим гнучкіший код

При проектуванні структури даних, чим простіший інтерфейс, тим гнучкіший код. Подивіться, наскільки потужний LINQ для демонстрації цього.

Як вибрати інтерфейси

Коли ви думаєте, що "список", ви повинні почати з того, щоб сказати собі: "Мені потрібно представити колекцію бейсболістів". Тож скажімо, ви вирішили моделювати це з класом. Перш за все, слід вирішити, який мінімальний об'єм інтерфейсів потрібно буде піддавати цьому класу.

Деякі питання, які можуть допомогти керувати цим процесом:

• Чи потрібно мені мати рахунок? Якщо не розглянути можливість здійсненняIEnumerable<T>
• Чи зміниться ця колекція після її ініціалізації? Якщо не враховувати IReadonlyList<T>.
• Чи важливо я мати доступ до елементів за індексом? РозглянемоICollection<T>
• Чи важливий порядок, в якому я додаю елементи до колекції? Може, це ISet<T>?
• Якщо ви справді хочете цього зробити, тоді продовжуйте та впроваджуйте IList<T>.

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

Використовуючи такий підхід, ви побачите, що код стає легше читати, переробляти та використовувати повторно.

Примітки про те, як уникати котельних плит

Реалізація інтерфейсів у сучасному IDE має бути простим. Клацніть правою кнопкою миші та виберіть "Реалізація інтерфейсу". Потім перешліть усі реалізації до класу-члена, якщо потрібно.

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

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

Проблеми з серіалізацією

Один аспект відсутній. Класи, які успадковуються зі списку <>, неможливо правильно серіалізувати за допомогою XmlSerializer . У такому випадку замість цього слід використовувати DataContractSerializer або потрібна власна серіалізаційна реалізація.

public class DemoList : List<Demo>
{
    // using XmlSerializer this properties won't be seralized:
    string AnyPropertyInDerivedFromList { get; set; }     
}

public class Demo
{
    // this properties will be seralized
    string AnyPropetyInDemo { get; set; }  
}

Подальше читання: Коли клас успадковується зі списку <>, XmlSerializer не серіалізує інші атрибути

Коли це прийнятно?

Щоб цитувати Еріка Ліпперта:

Коли ви будуєте механізм, який розширює List<T>механізм.

Наприклад, вам набридло відсутність AddRangeметоду в IList<T>:

public interface IMoreConvenientListInterface<T> : IList<T>
{
    void AddRange(IEnumerable<T> collection);
}

public class MoreConvenientList<T> : List<T>, IMoreConvenientListInterface<T> { }