Что, если у 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. X Y? или Имеет X Y?

2. Означают ли имена моих классов то, что они есть?

Дизайн> Реализация

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

Объект - это набор данных и поведения.

Итак, ваши первые вопросы должны быть такими:

• Какие данные содержит этот объект в создаваемой мной модели?
• Какое поведение этот объект демонстрирует в этой модели?
• Как это может измениться в будущем?

Имейте в виду, что наследование подразумевает отношение «isa» (есть), тогда как композиция подразумевает отношение «имеет» (hasa). Выберите наиболее подходящий для вашей ситуации, учитывая, что может происходить по мере развития вашего приложения.

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

Это не то, что все делают сознательно на этом уровне повседневного кодирования. Но если вы обдумываете такую ​​тему, вы попадаете в воды дизайна. Осознание этого может освободить.

Учитывайте особенности дизайна

Взгляните на List<T> и IList<T> в MSDN или Visual Studio. Посмотрите, какие методы и свойства они предоставляют. По вашему мнению, все эти методы похожи на то, что кто-то хотел бы сделать с FootballTeam?

Имеет ли для вас смысл footballTeam.Reverse()? footballTeam.ConvertAll<TOutput>() похоже на то, что вам нужно?

Это не вопрос с подвохом; ответ действительно может быть «да». Если вы реализуете / наследуете List<Player> или IList<Player>, вы застряли с ними; если это идеально подходит для вашей модели, сделайте это.

Если вы решите, что да, это имеет смысл, и вы хотите, чтобы ваш объект обрабатывался как набор / список игроков (поведение), и поэтому вы хотите реализовать ICollection<Player> или IList<Player>, обязательно сделайте так. Условно:

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 # поддерживает только одиночное наследование. (Если вы пробовали эту злобу в C ++, вы можете считать это хорошей вещью.) Реализация одной коллекции через наследование и другой через композицию, вероятно, покажется грязной. И такие свойства, как Count, сбивают пользователей с толку, если вы не реализуете ILIst<Player>.Count и IList<StaffMember>.Count и т. Д. Явно, и тогда они будут скорее болезненными, чем запутанными. Вы можете видеть, к чему это идет; Инстинктивное чувство, когда вы думаете об этом направлении, вполне может сказать вам, что вы считаете неправильным двигаться в этом направлении (и ваши коллеги, правильно или неправильно, могут также, если бы вы реализовали это таким образом!)

Короткий ответ (слишком поздно)

Рекомендация об отказе от наследования от классов коллекций не зависит от C #, вы найдете ее во многих языках программирования. Мудрость получена, а не закон. Одна из причин заключается в том, что на практике считается, что композиция часто побеждает наследование с точки зрения понятности, реализуемости и ремонтопригодности. С объектами реального мира / предметной области чаще встречаются полезные и согласованные отношения «hasa», чем полезные и согласованные отношения «isa», если только вы не глубоко вникаете в абстрактные, особенно когда проходит время и точные данные и поведение объектов в коде изменения. Это не должно заставлять вас всегда исключать наследование от классов коллекции; но это может показаться наводящим на размышления.

Прежде всего, это связано с удобством использования. Если вы используете наследование, класс Team будет предоставлять поведение (методы), которые разработаны исключительно для манипулирования объектами. Например, методы AsReadOnly() или CopyTo(obj) не имеют смысла для объекта группы. Вместо метода AddRange(items) вам, вероятно, понадобится более описательный метод AddPlayers(players).

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

Как уже упоминалось, композиция - это правильный путь. Просто реализуйте список игроков как частную переменную.

Позвольте мне переписать ваш вопрос. так что вы можете увидеть объект с другой точки зрения.

Когда мне нужно представлять футбольную команду, я понимаю, что это в основном имя. Нравится: "Орлы"

string team = new string();

Позже я понял, что в командах тоже есть игроки.

Почему я не могу просто расширить строковый тип, чтобы он также содержал список игроков?

Ваша точка входа в проблему произвольна. Постарайтесь подумать, что есть (свойства) у команды, а не то, что она есть .

После того, как вы это сделаете, вы сможете увидеть, разделяет ли он свойства с другими классами. И подумайте о наследовании.

Это зависит от контекста

Когда вы рассматриваете свою команду как список игроков, вы сводите «идею» футбольной команды к одному аспекту: вы сокращаете «команду» до людей, которых видите на поле. Этот прогноз верен только в определенном контексте. В другом контексте это могло бы быть совершенно неправильно. Представьте, что вы хотите стать спонсором команды. Так что вам нужно поговорить с менеджерами команды. В этом контексте команда проецируется в список ее менеджеров. И эти два списка обычно не очень сильно пересекаются. Другие контексты - это текущие игроки против бывших игроков и т. Д.

Неясная семантика

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

Классы расширяемы

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

Классы более сложные

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

Заключение / соображения

Когда у вас очень конкретный контекст, нормально рассматривать команду как список игроков. Например, внутри метода вполне нормально написать:

IList<Player> footballTeam = ...

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

type FootballTeam = IList<Player>

Но когда контекст более широкий или даже неясный, вам не следует этого делать. Это особенно актуально, когда вы создаете новый класс, чей контекст, в котором он может использоваться в будущем, не ясен. Предупреждающий знак - когда вы начинаете добавлять в свой класс дополнительные атрибуты (название команды, тренера и т. Д.). Это явный признак того, что контекст, в котором будет использоваться класс, не фиксирован и в будущем изменится. В этом случае вы не можете рассматривать команду как список игроков, но вы должны смоделировать список игроков (активных, не травмированных и т. Д.) Как атрибут команды.

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

Это логически неверно:

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

И это правильно:

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

Просто потому, что я думаю, что другие ответы в значительной степени зависят от того, является ли футбольная команда "является" List<FootballPlayer> или "имеет" List<FootballPlayer>, что на самом деле не отвечает на этот вопрос как написано.

OP в основном просит пояснить правила наследования от List<T>:

В руководстве говорится, что вы не должны наследовать от List<T>. Почему нет?

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

Что такое публичный API и почему меня это должно волновать?

Публичный API - это интерфейс, который вы предоставляете сторонним программистам. Подумайте о коде фреймворка. И помните, что упомянутые рекомендации - это «Рекомендации по проектированию .NET Framework », а не «Рекомендации по разработке приложений .NET ». Есть разница, и, вообще говоря, дизайн публичного API намного строже.

Если в моем текущем проекте нет и вряд ли когда-либо будет этот общедоступный API, могу ли я игнорировать это руководство? Если я унаследую от List и окажется, что мне нужен общедоступный 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);

Вообще имеет смысл? Если нет, то это не должен быть список.

Здесь есть много отличных ответов, но я хочу затронуть кое-что, о чем я не упоминал: объектно-ориентированный дизайн - это расширение возможностей объектов .

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

Когда вы наследуете от 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(...) изнутри.

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