したがって、この質問は、ここからの一種のフォローアップです（複数のイベント引数を処理する方法）。その質問は私にこれについて考えるように導きましたが、それ自身のスレッドを正当化するのに十分異なっています。
私は（楽しみと学習の目的で）ゲームを作成していますが、デザインに優れた基準を使用しているかどうかを知りたいです。関心の分離でOTTに移行したか、全体が間違っていたのではないかと思いますが、そうではないことを願っています。「ベストプラクティス」とその実用化を学びたいので、書き直しても問題ありません。
編集
ゲームについてもう少し説明しましょう。これは、多くの携帯電話で見られるゲームであるJawbreakerに基づいています（クイックデモはここにあります）。目的は、グループに含まれるボールを選択して、それらをプレーから除外し、できるだけ多くのポイントを獲得することです。
私はそれを少し拡張しようとしていて、ボードの種類、ボールの動き、ボールの種類が異なります。ボールは指示された場所に移動するか、途中で何かをする可能性があります。
これが私が作成したオブジェクトの構造です。上の行はDLLとそのオブジェクトを示し、2番目の行はそれらのオブジェクトが参照するものを示しています。
（出典：ggpht.com）
これがUMLを実行するための私の試みです。
UMLの全ページにリンクするには、ここをクリックしてください。少し大きくなり、読みやすくなります。
オブジェクトDLLは、ゲームで使用される基本的なオブジェクト、ボール、およびボードを保持します。それらには、状況にどのように作用/反応するかについてのロジックは含まれていません（ボールはCompareToメソッドとEqualsメソッドを実装しています）。IBallの実装はX個ある可能性があります（IBoardについても同じですが、私が想像するほど多くはありません）。
InstanceManager DLLは、オブジェクトを作成する方法として使用されます。これが100％必要であったかどうかは、ObjectsDLLに含まれている可能性があります。ファクトリは、IBallオブジェクトを作成するためのさまざまなオーバーロードされたメソッドを持つ静的クラスです。BallFactoryは、BallType列挙型、Drawing.Colorオブジェクトなどを受け取ることができます。BoardFactoryは非常によく似ています。Jawbreakerは、非常に定期的に使用されるランダムオブジェクトや一部のGameConfigurationデータ（このトピックにはあまり関係ありません）の保持などを処理するシングルトンオブジェクトです。
エンジンDLLは、ほとんどの作業が行われる場所です。LogicFactoriesは、BallTypeオブジェクトとBoardTypeオブジェクトを使用して、関連する論理オブジェクトを作成します。ロジックオブジェクトは、IBallおよびIBoardオブジェクトの動作を制御するために使用されます。BallLogicは、イベントが発生したときに何ができるかをボールに伝えます。たとえば、ボールが選択されると、ボードYのボールXが選択されたことを示すメソッドがボールロジックで呼び出されます。その後、ボールは、そのタイプのボールが実行すべき/実行できることは何でも実行できます。BoardLogicは非常によく似ており、ボードの動作を処理します。
エンジンオブジェクトは別のシングルトンであり、GUIがゲーム全体とどのように相互作用するかを示します。GUIは、他のオブジェクトを直接インスタンス化しません。
したがって、IBallクラスとIBoardクラスはそれらに関するデータのみを保持するため、Logicクラスはすべての機能を処理します。
私が知りたいのは：
1）これは賢明なアプローチですか？
2）（一般的に）ロジックはオブジェクト/データから分離する必要がありますか？
3）関心の分離に行き過ぎていませんか？
4）設計/構造に関するその他のコメント
編集
私がいくつかのシングルトンを使用した理由の一部は、オブジェクトを常に保持せずに1つの場所でデータにアクセスすることを簡単にするためです。また、単一のゲームであり、ハイエンドまたは複数のマシンにまたがってスケーリングされないためです。 。それらは素晴らしいものではなく、私が定期的に使用するものでもないことは理解していますが、コメントに感謝します。
ご意見・ご感想をお寄せいただきありがとうございます。