ウィザードとウォリアーのルールを回避する

でブログ記事のこのシリーズ、エリックリッペルトは、ウィザードとの例として、戦士を使用して、オブジェクト指向設計における問題点を説明します。

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、ウィザードがスタッフのみを使用できることをクラスに責任を持たせるなど）を示します。Liskov置換原則に違反したり、ランタイム例外のリスクを冒したり、拡張が困難なコードを作成したりする。

彼が思いついた解決策は、Playerクラスによって検証が行われないことです。状態の追跡にのみ使用されます。次に、プレイヤーに武器を与える代わりに：

player.Weapon = new Sword();

状態はCommands によって、sに従って変更されRuleます。

... 2つのゲーム状態オブジェクト（a とa）を取るCommandと呼ばれるオブジェクトを作成します。ユーザーがシステムにコマンドを発行すると、「このウィザードはその剣を振るう必要があります」と、一連のsを生成するsのセットのコンテキストでそのコマンドが評価されます。私たちは、1持っているプレイヤーの試みは、武器を振るうする際、効果は既存の武器は、存在する場合、廃棄され、新たな武器がプレイヤーの武器になることであると述べています。最初のルールを強化する別のルールがあります。つまり、ウィザードが剣を振るうとき、最初のルールの効果は適用されません。WieldPlayerWeaponRuleEffectRule

私はこのアイデアを原則として気に入っていますが、実際にどのように使用されるかについて懸念があります。

何も回避からの現像を防ぐように思わないCommandsとRule簡単に設定することで、秒WeaponにPlayer。Weaponプロパティがアクセスできる必要がありWield、それを行うことができないので、コマンドprivate set。

それで、開発者がこれを行うのを妨げているものは何ですか？彼らは覚えていないだけでいいですか？

一連のブログ投稿につながる議論全体は、パート5にあります。

C＃の型システムがダンジョンズ＆ドラゴンズのルールをエンコードするのに十分な一般性を持つように設計されていると信じる理由はありません。

「システムのルールを表すコードはどこにあるのか」という問題を解決しました。ゲームの状態を表すオブジェクトではなく、システムのルールを表すオブジェクトに入ります。状態オブジェクトの懸念は、状態を一定に保つことであり、ゲームのルールを評価することではありません。

武器、キャラクター、モンスター、その他のゲームオブジェクトは、何ができるか、何ができないかを確認する責任はありません。ルールシステムがその責任を負います。Commandオブジェクトは、いずれかのゲームオブジェクトと何もしていません。それは彼らと何かをしようとする試みを表すだけです。次に、ルールシステムは、コマンドが可能かどうかをチェックし、可能であれば、ゲームオブジェクトの適切なメソッドを呼び出してコマンドを実行します。

開発者が、最初のルールシステムでは許可されていない文字や武器を使用して処理を行う2番目のルールシステムを作成する場合、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
}

概要：要件をモデル化し、要件のみをモデル化します。データモデリングは行わないでください。これは、OOモデリングではありません。

1つの方法は、Wieldコマンドをに渡すことPlayerです。次に、プレーヤーはWieldコマンドを実行し、適切なルールをチェックしてを返しますWeapon。これによりPlayer、独自の武器フィールドが設定されます。このように、Weaponフィールドはプライベートセッターを持つことができWield、プレイヤーにコマンドを渡すことによってのみ設定できます。

開発者がそうすることを妨げるものは何もありません。実際、エリック・リッパートはさまざまなテクニックを試しましたが、すべてに弱点がありました。それがそのシリーズの要点であり、開発者がそうするのを止めることは容易ではなく、彼が試みたすべてに欠点がありました。最後にCommand、ルール付きのオブジェクトを使用する方法を選択することにしました。

ルールを使用すると、aのWeaponプロパティをa Wizardに設定できますが、武器（剣）を装備して攻撃Swordするように要求しWizardても、効果はなく、状態は変化しません。彼が以下に言うように：

最初のルールを強化する別のルールがあります。つまり、ウィザードが剣を振るうとき、最初のルールの効果は適用されません。その状況の影響は、「悲しいトロンボーンサウンドを作り、ユーザーはこのターンのアクションを失います。ゲームの状態は変化しません。

言い換えれば、type彼が多くの異なる方法を試みたが、それを好きではなかった、または機能しなかった関係によって、そのようなルールを強制することはできません。したがって、彼が実行できると彼が言った唯一のことは、実行時にそれについて何かをすることです。彼はそれを例外とは考えていないので、例外を投げることは良くありませんでした。

彼は最終的に上記の解決策を選択しました。このソリューションでは、基本的に任意の武器を設定できると述べていますが、それを放棄した場合、適切な武器ではないとしても、それは本質的に役に立たないでしょう。ただし、例外はスローされません。

それは良い解決策だと思います。いくつかのケースでは私もトライセットパターンで行きます。

著者の最初の破棄された解決策は、型システムでルールを表現することでした。型システムはコンパイル時に評価されます。ルールを型システムから切り離すと、ルールはコンパイラーによってチェックされなくなるため、開発者自身が間違いを犯さないようにするものはありません。

しかし、この問題は、コンパイラーによってチェックされないすべてのロジック/モデリングが直面しており、これに対する一般的な答えは（ユニット）テストです。したがって、著者の提案するソリューションには、開発者によるエラーを回避するための強力なテストハーネスが必要です。実行時にのみ検出されるエラーに対して強力なテストハーネスが必要であるというこのポイントを強調するには、動的言語での強力なテストのために強力な型付けを交換する必要があると主張するBruce Eckelによるこの記事を参照してください。

結論として、開発者が間違いを犯さないようにすることができる唯一のことは、すべてのルールが遵守されていることをチェックする一連の（ユニット）テストを行うことです。

ここで微妙なところを見逃したかもしれませんが、問題が型システムにあるかどうかはわかりません。多分それはC＃の慣習にあります。

たとえば、Weaponセッターをで保護することにより、これを完全にタイプセーフにすることができますPlayer。次に、保護されたセッターを呼び出すsetSword(Sword)andとsetStaff(Staff)to WarriorをWizardそれぞれ追加します。

このようにして、Player/ Weapon関係は静的にチェックされ、気にしないコードはを使用してPlayerを取得できますWeapon。

それで、開発者がこれを行うのを妨げているものは何ですか？彼らは覚えていないだけでいいですか？

この質問は、「検証をどこに置くか」と呼ばれるかなり聖戦的なトピックと事実上同じです（おそらくdddにも注意してください）。

したがって、この質問に答える前に、自問する必要があります。従う必要があるルールの性質は何ですか？彼らは石に彫られて、実体を定義していますか？これらの規則に違反すると、エンティティはそれが何であるかを停止しますか？はいの場合は、これらのルールをコマンドの検証で維持するとともに、それらもエンティティに配置します。したがって、開発者がコマンドの検証を忘れた場合、エンティティは無効な状態にはなりません。

そうでない場合、まあ、それは本質的に、このルールがコマンド固有であり、ドメインエンティティに存在すべきではないことを意味します。そのため、このルールに違反すると、許可されていないはずのアクションが発生しますが、モデルの状態は無効ではありません。