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

Попытка №3

abstract class Player 
{
  public Weapon Weapon { get; set; }
}

sealed class Wizard : Player
{
  public new Staff Weapon 
  {
    get { return (Staff)base.Weapon; }
    set { base.Weapon = value; }
  }
}

У этого кода есть приятное свойство: если у вас есть ссылка на Волшебника, публичный интерфейс дает вам Посох когда вы запрашиваете Оружие, а система типов не позволяет вам присвоить Меч в качестве Оружия Волшебника.

Но у него есть не очень приятные свойства. Мы по-прежнему нарушаем Принцип Подстановки Лисков (LSP): если у нас есть ссылка на Игрока, мы можем без ошибок присвоить Меч в качестве Оружия:

Wizard wizard = new Wizard();
Player player = wizard;
player.Weapon = new Sword(); // Отлично
Staff staff = wizard.Weapon; // Упс!

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

Мы могли бы решить эту проблему следующим образом:

abstract class Player 
{
  public Weapon Weapon { get; protected set; }
}

Теперь, если вы хотите присвоить оружие, вам нужна ссылка на Волшебника, а не на Игрока, а сеттер обеспечивает безопасность типов.

Это довольно хорошо, но все же не отлично. Если у нас есть ссылка на Волшебника и Посох в руке, то все хорошо. Но Волшебник находится в переменной типа Игрок, тогда нам нужно знать, к какому типу привести Игрока, чтобы сделать то, что является допустимым действием, но не разрешенным для типа Игрока. И, конечно же, та же проблема возникает, если Посох находится в переменной типа Оружие; теперь мы должны знать, к чему его привести, чтобы задать свойство.

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

Попытка №4

Интерфейсы! Да, это вариант.

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

interface IPlayer 
{
  Weapon Weapon { get; set; }
}

sealed class Wizard : IPlayer
{
  Weapon IPlayer.Weapon 
  {
    get { return this.Weapon; }
    set { this.Weapon = (Staff) value; }
  }
  public Staff Weapon { get; set; }
}

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

Хотя это популярное решение, на самом деле мы просто передвигаем проблему, а не исправляем ее. Полиморфизм по-прежнему полностью сломан, потому что кто-то может иметь ссылку на IPlayer и присвоить Меч в качестве Оружия, что вызовет исключение. Интерфейсы в том виде, в каком мы их использовали здесь, по существу ничем не лучше абстрактных базовых классов.

Попытка №5

Пришло время доставать большие пушки - ограничения обобщенных типов (generic constraints)! Да, детка!

abstract class Player<TWeapon>  where TWeapon : Weapon
{
  TWeapon Weapon { get; set; }
}
sealed class Wizard : Player<Staff> { }
sealed class Warrior : Player<Sword> { }

Это настолько ужасно, что я даже не знаю, с чего начать, но я попытаюсь.

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

Мы могли бы решить эту проблему, наследуя обобщенный тип Игрока<Оружие> от необобщенного типа Игрока, у которого нет свойства Оружия, но теперь вы не можете воспользоваться тем фактом, что у Игрока есть Оружие, если у вас есть ссылка на необобщенного Игрока.

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

В-третьих, похоже, что это не будет масштабироваться. Если я хочу также сказать «игрок может носить доспехи, а волшебник может носить только мантию», и «игрок может читать книги, а воин может читать только немагические книги» и так далее, мы собираемся получить полдюжины аргументов типа Игрок?

Попытка №6

Объединим попытки 4 и 5. Проблема возникает, когда мы пытаемся менять оружие. Мы могли бы сделать классы игроков иммутабельными, создавать нового игрока каждый раз, когда меняется оружие, и теперь мы можем сделать интерфейс ковариантным. Хотя я большой поклонник иммутабельности, мне не очень нравится это решение.

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

Ах да, еще кое-что. Увидев Арагорна с его арсеналом, я вспомнил, упоминал ли я ранее, что и волшебники, и воины могут использовать кинжалы?

Возможно, ваши пользователи всегда точно сообщают вам точные ограничения предметной области, прежде чем вы начнете кодировать каждый проект, и они никогда не изменятся в будущем. Ну я не такой пользователь. Мне нужно, чтобы система учитывала тот факт, что и волшебники, и воины могут использовать кинжалы, и нет, кинжалы не являются «особым видом меча», так что даже не спрашивайте.

Попытка №7

Очевидно, что здесь нам нужно объединить все методы, которые мы видели до сих пор в этом эпизоде:

sealed class Wizard : 
  IPlayer<Staff, Robes> , 
  IPlayer<Dagger, Robes>
{ ...

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

Оставим пока в стороне проблему посохов и мечей и рассмотрим связанную с ней проблему проектирования иерархии классов: предположим, паладин замахивается мечом на оборотня в церкви после полуночи. Это касается класса игрока, монстра, оружия или локации? Или, может быть, какая-то их комбинация? И если типы ни одного из них не известны во время компиляции, что тогда? Об этом в следующем выпуске.