Обход правил у волшебников и воинов

В этой серии постов в блоге Эрик Липперт описывает проблему объектно-ориентированного проектирования на примере мастеров и воинов, где:

abstract class Weapon { }
sealed class Staff : Weapon { }
sealed class Sword : Weapon { }

abstract class Player 
{ 
  public Weapon Weapon { get; set; }
}
sealed class Wizard : Player { }
sealed class Warrior : Player { }

а затем добавляет пару правил:

• Воин может использовать только меч.
• Волшебник может использовать только посох.

Затем он продолжает демонстрировать проблемы, с которыми вы сталкиваетесь, если вы пытаетесь применить эти правила с помощью системы типов C # (например, Wizardвозложить на класс ответственность за то, чтобы мастер мог использовать только персонал). Вы нарушаете принцип подстановки Лискова, рискуете получить исключения во время выполнения или получаете код, который сложно расширить.

Решение, которое он предлагает, заключается в том, что класс Player не выполняет проверку. Он используется только для отслеживания состояния. Затем вместо того, чтобы дать игроку оружие:

player.Weapon = new Sword();

состояние изменяется Commands и в соответствии с Rules:

... мы создаем Commandобъект с именем, Wieldкоторый принимает два объекта состояния игры, a Playerи a Weapon. Когда пользователь выдает команду системе «этот волшебник должен владеть этим мечом», тогда эта команда оценивается в контексте набора Rules, который создает последовательность Effects. У нас есть такой, Ruleкоторый говорит, что когда игрок пытается владеть оружием, эффект состоит в том, что существующее оружие, если оно есть, сбрасывается, и новое оружие становится оружием игрока. У нас есть другое правило, которое усиливает первое правило, которое гласит, что эффекты первого правила не применяются, когда волшебник пытается владеть мечом.

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

Кажется, ничто не мешает разработчику обойти « Commandsи Rule», просто установив « Weaponна» Player. WeaponСобственности должны быть доступны по Wieldкоманде, так что это не может быть сделаны private set.

Итак, что же предотвратить разработчик делать это? Они просто должны помнить, чтобы не делать?

Весь аргумент, к которому приводит серия постов в блоге, находится в пятой части :

У нас нет оснований полагать, что система типов C # была разработана с достаточной общностью для кодирования правил Dungeons & Dragons, так почему же мы даже пытаемся?

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

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

Если разработчик хочет создать вторую систему правил, которая работает с персонажами и оружием, чего не позволила бы первая система правил, он может сделать это, потому что в C # вы не можете (без неприятных взломов отражений) выяснить, откуда происходит вызов метода от.

Обходной путь, который может работать в некоторых ситуациях, - поместить игровые объекты (или их интерфейсы) в одну сборку с механизмом правил и пометить любые методы-мутаторы как internal. Любые системы, которым нужен доступ только для чтения к игровым объектам, будут находиться в другой сборке, что означает, что они смогут получить доступ только к publicметодам. Это все еще оставляет лазейку игровых объектов, вызывающих внутренние методы друг друга. Но делать это было бы очевидным запахом кода, потому что вы согласились, что классы игровых объектов должны быть глупыми держателями состояний.

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

Я бы начал с попыток получить реальные функциональные требования. Например: «Любой игрок может атаковать других игроков, ...». Вот:

interface Player {
    void Attack(Player enemy);
}

«Игроки могут владеть оружием, которое используется при атаке, Волшебники могут владеть Посохом, Воинами - Мечом»:

public class Wizard: Player {
    ...
    public void Wield(Staff weapon) { ... }
    ...
}
public class Warrior: Player {
    ...
    public void Wield(Sword sword) { ... }
    ...
}

«Каждое оружие наносит урон атакующему врагу». Хорошо, теперь у нас должен быть общий интерфейс для оружия:

interface Weapon {
    void dealDamageTo(Player enemy);
}

И так далее ... Почему нет Wield()в Player? Потому что не было требования, чтобы любой игрок мог владеть любым оружием.

Я могу представить, что будет требование, гласящее: «Любой Playerможет попытаться овладеть любым Weapon». Это было бы совсем другое дело, однако. Я бы смоделировал это возможно так:

interface Player {
    void Attack(Player enemy);
    void TryWielding(Weapon weapon); // Throws UnwieldableException
}

Резюме: смоделируйте требования и только требования. Не занимайтесь моделированием данных, это не моделирование.

Одним из способов было бы передать Wieldкоманду Player. Затем игрок выполняет Wieldкоманду, которая проверяет соответствующие правила и возвращает команду Weapon, с которой Playerзатем устанавливает свое собственное поле оружия. Таким образом, поле «Оружие» может иметь приватный сеттер и может быть установлено только путем передачи Wieldкоманды игроку.

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

С помощью правил вы можете установить для Weaponсвойства a Wizardзначение a, Swordно когда вы попросите Wizardего владеть оружием (мечом) и атаковать его, оно не будет иметь никакого эффекта и, следовательно, не изменит никакого состояния. Как он говорит ниже:

У нас есть другое правило, которое усиливает первое правило, которое гласит, что эффекты первого правила не применяются, когда волшебник пытается владеть мечом. Эффекты для этой ситуации: «издавать грустный звук тромбона, пользователь теряет свои действия в этом ходу, состояние игры не изменяется

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

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

Я думаю, что это хорошее решение. Хотя в некоторых случаях я бы тоже использовал шаблон try-set.

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

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

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

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

Например, вы можете сделать этот тип полностью безопасным, Weaponзащитив сеттер Player. Затем добавьте setSword(Sword)и setStaff(Staff)к Warriorи Wizardсоответственно, что вызывает защищенный сеттер.

Таким образом, отношение Player/ Weaponпроверяется статически, и код, который не заботится, может просто использовать a Playerдля получения Weapon.

Итак, что мешает разработчику сделать это? Они просто должны помнить, чтобы не делать?

Этот вопрос фактически совпадает с темой «святой войны», называемой « где поставить проверку » (скорее всего, также отмечая DDD).

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

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