Обхід Правил у Чарівниках та Воїнах

У цій серії публікацій блогу Ерік Ліпперт описує проблему в об'єктно-орієнтованому дизайні, використовуючи в якості прикладів майстрів та воїнів, де:

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.Weapon = new Sword();

стан модифікується Commands і відповідно до Rules:

... ми робимо Commandоб'єкт під назвою, Wieldякий займає два об'єкти стану гри, a Playerі a Weapon. Коли користувач видає команду системі "цей майстер повинен володіти цим мечем", тоді ця команда оцінюється в контексті набору Rules, який створює послідовність Effects. У нас є одна, Ruleяка говорить про те, що коли гравець намагається скласти зброю, наслідком є ​​те, що існуюча зброя, якщо така є, скидається, а нова зброя стає зброєю гравця. У нас є ще одне правило, яке посилює перше правило, яке говорить про те, що ефекти першого правила не застосовуються, коли майстер намагається обрушити меч.

Мені в принципі подобається ця ідея, але я хвилююсь, як вона може бути використана на практиці.

Здається, ніщо не заважає розробнику обійти Commandsі Rules, просто встановивши значення Weapona 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потім встановлює власне поле Зброя. Таким чином, поле Weapon може мати приватний сеттер і встановлюється лише за допомогою передачі Wieldкоманди гравцеві.

Ніщо не заважає розробнику цього робити. Насправді Ерік Ліпперт спробував багато різних методик, але всі вони мали слабкі сторони. У цьому і полягала вся суть цієї серії в тому, що зупинити розробника від цього непросто, і все, що він намагався, мало недоліки. Нарешті він вирішив, що використовувати Commandоб’єкт із правилами - це шлях.

За допомогою правил ви можете встановити Weaponвластивість a Wizardбути a, Swordале коли ви попросите, Wizardщоб він мав зброю (Меч) і нападав на неї, це не матиме жодного ефекту, і тому це не змінить жодного стану. Як він каже нижче:

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

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

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

Я думаю, що це гарне рішення. Хоча в деяких випадках я б також пішов із схемою спробувати.

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

Але з цією проблемою стикається кожна логіка / моделювання, що не перевіряється компілятором, і загальною відповіддю на це є (одиничне) тестування. Тому запропоноване автором рішення потребує міцного тестового використання, щоб обійти помилки розробників. Щоб підкреслити цю точку необхідності міцного тестового використання для помилок, виявлених лише під час виконання, перегляньте цю статтю Брюса Еккеля, яка робить аргумент, що вам потрібно обмінятись сильним типізацією для більш сильного тестування в динамічних мовах.

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

Я, можливо, тут пропустив тонкощі, але я не впевнений, що проблема полягає в системі типів. Можливо, це з умовою в C #.

Наприклад, ви можете зробити цей повністю безпечним типом, зробивши Weaponзахищений сетер Player. Потім додати setSword(Sword)і setStaff(Staff)до Warriorі , Wizardвідповідно , цього виклику захищеного сетера.

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

Отже, що заважає розробнику робити це? Вони просто повинні пам’ятати, щоб цього не робити?

Це питання фактично те саме, що стосується досить священної війни під назвою " куди слід перевірити " (швидше за все, відзначаючи і DDD).

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

Якщо ні - добре, це по суті означає, що ці правила є специфічними для команд і не повинні розміщуватися в доменних об'єктах. Таким чином, порушення цих правил призводить до дій, які не повинні були бути дозволені, але не в недійсному стані моделі.