コマンドとメディエーターのパターンの違いは何ですか？
私のボードゲームでは、今度は駒の移動システムを何度か変更し、毎回面倒なので、PlayerクラスとBoardクラスを分離したいと思います。ボードの状態を変更するためにプレーヤーのリクエストを取得するためにいくつかのインターフェイスを使用できると思いますが、コマンドまたはMediatorインターフェイスが適切なソリューションであるかどうかを判断できません（またはオブザーバーですか？）
私の理解では、コマンドは、クライアントがレシーバーに対して実行したいことを、実行方法を知らないまま実行します。しかし、メディエーターはほとんど同じことをしませんか？リクエストオブジェクトを指定すると、メディエーターがクライアントに代わってリクエストを実行しますか？メディエーターは双方向通信を容易にしますか？プレイヤーは駒の移動をリクエストできますが、成功した場合、ボードはプレイヤーに新しいボードの状態を通知できますか？
基本的に、3つの関連しているように見えるパターン間でクラスを分離する方法を知るのに苦労しています。私はこれに関するGoFの議論を読みましたが、彼らがお互いに役立つときの具体的な例を使用していないので、私はまだ混乱しています。
それは正しい質問ですか？
Mediatorは、お互いを知らない「同僚」オブジェクト間の相互作用についてです。 Commandは、1つの特定の対話を実行する方法についてです（コマンドがプレーヤーによって作成されたかメディエーターによって作成されたかに関係なく）。したがって、問題はどの代替案を使用するかではなく、それぞれがどのように目的を果たすことができるかについてです。
メディエーターはどのように役立ちますか？
メディエーターパターン の目的は、複数の同僚オブジェクト間の相互作用をカプセル化して、それらを互いに分離することです。メディエーターを使用してPlayerとBoardを分離すると、設計が少し複雑になります。
PlayerとBoardは同じ共通のColleagueインターフェースを実装しますPlayerはMediatorに移動リクエストを送信しますMediatorは、プレーヤーのリクエストがBoardに送信されることを認識していますBoardはMediatorからリクエストを受け取りますBoardリクエストを分析し、Mediatorにそれが受け入れられた（または拒否された）ことを通知しますMediatorは、このようなやり取りがPlayerに送信されることを知っていますPlayerはMediatorから回答を受け取ります
さらに、GoFで述べたように、メディエーターをさまざまな同僚のオブザーバーにして、関連する状態の変化を通知し、アクションをトリガーできるようにすると便利です。
このより複雑なアプローチの利点は、その柔軟性です。たとえば、2 PlayersとBoardを使用できます。タイマーColleagueを追加できます。顧問/コーチColleagueを追加して、人間の動きがどれほど優れているかを人間のプレーヤーに知らせる（または同様の情報を機械学習AIプレーヤーに提供する）ことができます。
さらに、同僚が切り離されているため、他のゲームでそれらを再利用できる可能性があります。
コマンドはどうですか？
コマンドパターン の目的は、リクエストをカプセル化することです。したがって、ボードの動きをカプセル化し、それらを実行できるようにします（またはユーザーが取り消しをアクティブにした場合は逆にします）。
PlayerにBoardの状態変化を観察させるために、必ずオブザーバーパターンを使用します。また、2番目のPlayer（AIまたは人間）もBoard変更をサブスクライブし、移動をトリガーするコマンドを発行します。また、ゲームのメインループがあり、タイマーを追加できます。
最終的には、同様の構造になります（ゲームループがピースを接着します）。ただし、オブジェクトは相互に認識している必要があり、オブジェクト間の相互作用の変更には、関連するすべてのクラスの適応が必要になる場合があります。
推奨事項
- 取り消しを許可する場合は、
Commandを使用することをお勧めします。 - 同僚が2人しかいない場合、ゲームが1つしかない場合、メディエーターは少し過剰に設計されているように見えます。さらに、デザインの残りの部分を制約する可能性があります。したがって、おそらくそれなしで開始し、何かが機能しているときにコードをリファクタリングします。
- ゲームコーディング全般に興味がある場合は、Mike McShaffryの著書「Game Coding Complete」が役立ちます。彼は、ゲームの構成方法、課題、および回避すべき落とし穴について説明しています。パターンについての理論はあまりありませんが、実際のゲームアーキテクチャについての常識はたくさんあります。