Что делать, если 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 это звучит неправильно. A Team больше, чем Collection. В Team могут быть тренеры, тренеры и т. Д., Как указывали другие ответы.

FootballCollection звучит как сборник футбольных мячей или, может быть, коллекция футбольных принадлежностей. TeamCollection, сборник команд.

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

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

В резюме

Задайте вопрос

1. Is X a Y? или Имеет X a Y?
2. Знают ли мои имена классов, каковы они?

Как все отметили, команда игроков не является списком игроков. Эта ошибка совершается многими людьми во всем мире, возможно, на разных уровнях знаний. Часто проблема тонкая, а иногда и очень грубая, как в этом случае. Такие проекты плохи, потому что они нарушают Принцип замещения Лискова. В Интернете есть много хороших статей, объясняющих эту концепцию, например http://en.wikipedia.org/wiki/Liskov_substitution_principle

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

• a Ребенок не должен иметь никакой характеристики, которая меньше, чем то, что полностью определяет родителя.
• Родитель должен не требовать характерный в дополнение к тому, что полностью определяет ребенка.

Другими словами, родитель является необходимым определением для ребенка, а ребенок является достаточным определением родителя.

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

• Является ли футбольная команда списком футболистов? (Все ли свойства списка относятся к команде в том же значении) Является ли команда коллекцией однородных объектов? Да, команда - это сборник игроков. Является ли порядок включения игроков в описание состояния команды и обеспечивает ли команда сохранение последовательности, если она явно не изменена? Нет, и Нет. Ожидается, что игроки будут включены / сброшены на основе их последовательной позиции в команде? Нет

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

На этом этапе я хотел бы отметить что класс Team должен, на мой взгляд, даже не реализовываться с использованием List; в большинстве случаев он должен быть реализован с использованием структуры данных Set (например, HashSet).

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

Я часто вижу, что многие люди делают тонны дополнительной работы только из-за Правило FxCop говорит так, или чей-то блог говорит, что это «плохая» практика. Много раз, это превращает код в дизайн палодовости паттерн. Как и в случае с множеством рекомендаций, относитесь к нему как к руководящему принципу, который может иметь исключения.

Наконец, некоторые предлагают обернуть список в чем-то:

Это правильный путь. «Безусловно многословие» - это плохой способ взглянуть на это. Он имеет явное значение, когда вы пишете my_team.Players.Count. Вы хотите подсчитать игроков.

my_team.Count

.. ничего не значит. Считайте что?

Команда не является списком - состоят не только из списка игроков.

Если вы действительно обеспокоены тем, что он слишком многословный, вы всегда можете выставлять свойства из команда:

public int PlayerCount {
    get {
        return Players.Count;
    }
}

.. которая становится:

my_team.PlayerCount

Теперь это имеет смысл и придерживается Закона Деметры .

Вы также должны рассмотреть возможность соблюдения принципа повторного использования Composite . Наследуя от List<T>, вы говорите, что команда - это список игроков и выставляя из нее ненужные методы. Это неверно. Как вы сказали, команда - это больше, чем список игроков: у нее есть имя, менеджеры, члены совета, тренеры, медицинский персонал, зарплата и т. Д. Если ваш класс команды содержит список игроков, вы «У команды есть список игроков», но у нее также могут быть и другие вещи.

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

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

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

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

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

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

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

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

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

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

IList<Player> footballTeam = ...

При использовании F # может даже быть ОК, чтобы создать аббревиатуру типа

type FootballTeam = IList<Player>

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

Это зависит от поведения вашего «командного» объекта. Если он ведет себя точно так же, как в коллекции, возможно, это будет нормально представлять его сначала с помощью простого списка. Тогда вы можете начать замечать, что вы продолжаете дублировать код, который повторяется в списке; на данный момент у вас есть возможность создать объект FootballTeam, который обертывает список игроков. Класс FootballTeam становится домом для всего кода, который повторяется в списке игроков.

Это делает мой код излишне подробным. Теперь я должен назвать my_team.Players.Count вместо my_team.Count. К счастью, с C # я могу определить индексаторов, чтобы сделать индексирование прозрачным, и переслать все методы внутреннего списка ... Но это много кода! Что я могу получить за все это?

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

Это просто не имеет никакого смысла. Футбольная команда не имеет «списка» игроков. Это список игроков. Вы не говорите: «Джон Макфуталлер присоединился к игрокам SomeTeam». Вы говорите: «Джон присоединился к SomeTeam». Вы не добавляете письмо в «символы строки», вы добавляете письмо к строке. Вы не добавляете книгу в книги библиотеки, вы добавляете книгу в библиотеку.

Точно :) вы скажете footballTeam.Add (john), а не footballTeam.List.Add (Джон). Внутренний список не будет виден.

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

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

string team = new string();

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

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

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

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

Предпочитают интерфейсы над классами

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

Inheritance breaks Encapsulation

Вывод из классов прерывает инкапсуляцию :

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

. Среди прочего это затрудняет реорганизацию вашего кода.

Классы являются частью реализации

Классы - это детали реализации, которые должны быть скрыты от других частей вашего кода. Короче говоря, 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 .

Это классический пример состава против наследования .

В этом конкретном случае:

Является ли команда списком игроков с добавленным поведением

или

Является ли команда собственностью, которая, как оказалось, содержит список игроков.

Расширяя список, вы ограничиваете себя несколькими способами:

1. Вы не можете ограничить доступ (например, остановить людей, изменяющих список). Вы получаете все методы List, хотите ли вы / хотите их всех или нет.

2. Что произойдет, если вы хотите иметь списки других вещей. Например, в командах есть тренеры, менеджеры, болельщики, оборудование и т. Д. Некоторые из них вполне могут быть списками в своем собственном праве.

3. Вы ограничиваете свои варианты наследования. Например, вы можете создать общий объект Team, а затем получить BaseballTeam, FootballTeam и т. Д. Чтобы наследовать из списка, вам нужно наследовать от Team, но это означает, что все команды разных типов вынуждены иметь одну и ту же реализацию этого списка.

Состав - включая объект, дающий поведение, которое вы хотите в своем объекте.

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

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