ブラウザーゲームでロジックとデータを分離する

私はこれを何日も考えてきましたが、どうすればよいかわかりません。私はPHPで戦闘システムをリファクタリングしようとしています（...申し訳ありません。）これまでに存在したものは次のとおりです。

• これまでのところ、戦闘に参加できるエンティティには2つのタイプがあります。それらをプレイヤーとNPCと呼びましょう。彼らのデータはすでにかなりよく書かれています。
• 戦闘に関与する場合、これらのエンティティはと呼ばれるDB内の別のオブジェクトでラップされCombatant、特定の戦いに関する情報を提供します。彼らは一度に複数の戦闘に参加することができます。
• 戦闘員を投入して戦闘用のロジックエンジンを作成しようとしています。
• テスト用にすべてを模擬できるようにしたい。

ロジックとデータを分離するために、私は2つのインターフェース/基本クラス、ICombatantDataつまり1つともう1つを用意したいと考えていますICombatantLogic。データの2つの実装者は、データベースに格納されている実際のオブジェクト用と、モックオブジェクト用です。

私は今、物事の論理的な側面を設計することに関して不確実性にぶつかっています。プレイヤーとNPCごとに1つの実装者を指定できますが、問題があります。戦闘員は、ラップするエンティティを返すことができる必要があります。このゲッターメソッドはロジックまたはデータの一部である必要がありますか？ロジック部分は戦闘の実行に使用されるため、データ内にあるべきだと強く思います。誰かが今度の戦いについての情報を探しているだけでは利用できません。しかし、データクラスはDBからモックのみを分離し、NPCからのプレーヤーは分離しません。DBデータインプリメンターの2つの子クラス（エンティティタイプごとに1つ）を試してみる場合、モックをループに維持しながらどのように設計すればよいですか？IEntityProviderデータクラスに注入するような3つ目のインターフェイスが必要ですか？

また、私が検討していたいくつかのアイデアでは、NPCのロジックが誤ってプレーヤーのデータをラップするなど、不一致がないことを確認するためにチェックを配置する必要があると思います。それは意味がありますか？それは、アーキテクチャが正しい場合にさえ起こり得る状況でしょうか、それとも、適切な設計がそれを完全に禁止しているので、チェックする必要がないのでしょうか？

誰かがクラス図などをレイアウトするのを手伝ってくれるなら、それはとても役に立ちます。ありがとう。

編集する

また、モックデータクラスではは実際には必要ありませんEntity。代わりに、戦闘統計のようなすべてのパラメーターを直接指定しているだけです。おそらくそれは正しい設計に影響を与えるでしょう。

これまで私がこれに取り組んだ方法の1つは、プレイヤーとNPCの表現を完全に分離するのではなく、両方に共通のインターフェイスを実装することを要求することです。Character一般化するのが理にかなっているのと同じくらいそれらをプッシュする共通のモデルからそれらをサブクラス化することによって。これにより、完全に独立した実装である場合よりも表現が分岐する自然な傾向が少なくなるため、操作をより一般的に適用できるようにすることで、プレーヤーでのNPC操作の実行などの問題を回避できます。ポリモーフィズムの基本的な活用は、分岐する必要があるケースの処理に役立ちます（たとえば、CombatantLogic誰かが死んだときに何が起こるかを処理する責任がある場合は、型チェックを実行して、正しいロジックを使用していることを確認する必要があります。そうしないでください、プレーヤーとNPCに個別の適切なdie()メソッドを実装してもらいます）。

あなたEntityがデータの一部であることに同意します。ただし、私が言っていることにCombatantData基づいて、戦闘ロジックがから直接値を引き出すように、実際にはあなたの役割を削除または制限する傾向がありますEntity。おそらく、CombatantData高価な単一の戦闘固有の計算値のみを格納します。その場合、テストモックアップは、実装Entityよりも偽のモデルを提供することに重点が置かれCombatantDataます。（非正規化されたデータベースが行うのとほとんど同じ方法でCombatantData、Entity迷惑メールから多くの情報を重複させます。しかし、私が情熱的にそうしていないデメテルの法則を信じるなら、あなたは私がそうすることをしたくないでしょう。もちろん、あなたがデメテルの法則を信じているなら、私はあなたのことを確信していませんCombatantDataへのアクセスも提供する必要がありEntityます。）