アプリケーションの設計/構造の問題と懸念の分離

design-patterns separation-of-concerns
アプリケーションの設計/構造の問題と懸念の分離

したがって、この質問はここからの一種のフォローです(https://stackoverflow.com/questions/1914097/how-to-deal-with-multiple-event-args [複数のイベント引数の処理方法])。 その質問から、これについて考えるようになりましたが、独自のスレッドを保証するのに十分なほど異なっています。

私はゲームを作成していて(楽しく学習するため)、デザインに良い基準を使用しているかどうかを知りたいと思っています。 関心の分離にOTTを使用したか、またはすべてを間違っただけだったかもしれませんが、そうではないことを望んでいます。 「ベストプラクティス」とそれらの実用化を学びたいので、書き直しても問題ありません。

編集

ゲームについてもう少し説明しましょう。これは、多くの携帯電話で見られるゲームJawbreakerに基づいています(http://bigfrog.n​​et/jawbreaker/[quick demo found here])。 目的は、グループ内のボールを選択してプレーから除外し、できるだけ多くのポイントを獲得することです。

私はそれを少し拡大しようとしており、さまざまな種類のボード、ボールのさまざまな方法、ボールの種類があります。ボールは指示された場所に移動するか、途中で何かをする可能性があります。

したがって、作成したオブジェクトの構造は次のとおりです。一番上の行にはDLLがオブジェクトとともに表示され、2番目の行にはそれらのオブジェクトが参照するものが表示されます。

UMLを実行しようとする私の試みは次のとおりです。

http://yuml.me/3279d2ac [ここをクリックしてUMLの全ページにリンクすると、少し大きくなり、できれば読みやすくなります]

オブジェクトDLLは、ゲーム、ボール、ボードで使用される基本的なオブジェクトを保持します。 状況に対するアクション/反応の方法に関するロジックは含まれていません(ボールはCompareToメソッドとEqualsメソッドを実装しています)。 IBallの実装はX個あります(IBoardでも同じですが、想像するほど多くはありません)。

InstanceManager DLLはオブジェクトを作成する方法として使用されますが、これがオブジェクトDLLに含まれている可能性が100%必要であるかどうかはわかりません。 ファクトリは、IBallオブジェクトを作成するためのさまざまなオーバーロードメソッドを持つ静的クラスです。 BallFactoryは、BallType Enum、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つは、オブジェクトを常に保持せずに1か所でデータに簡単にアクセスできることと、それが単一のゲームであり、ハイエンドまたは複数のマシンにわたってスケーリングされないという理由だけです。 それらは素晴らしいものではなく、私が定期的に使用しているものではないことを理解していますが、コメントに感謝します。

あなたの考えとフィードバックをありがとう。

  0  1


ベストアンサー

あなたの内訳は正しい方向に進んでいるように見えます。 ただし、ロジックからのプレゼンテーションからデータを分離しようとしているのかどうかはわかりません。 MVC、オブザーバー、および戦略パターンを見てください。

これを念頭に置いてください:疎結合のアプリケーションを設計する場合には、トレードオフがあります。 少ない労力でアプリケーションを拡張できますが、パフォーマンスとメモリ使用量は少なくなります。 また、私はこれを言うのが嫌いですが、不要なインターフェイスを作成しないでください。 インターフェースを作成するときに、オブジェクトの機能を今すぐまたは後で拡張することがわかっている場合は、実装する前に考えないでください。

2


何をしようとしているのかをよく理解しなければ、デザインを批判することは困難です。 ボールとボードが関係していることは知っていますが、それ以外はわかりません。

できるだけシングルトンを避けるようにしてください。 はい、GoFの本にリストされていることは知っていますし、それが一般的なパターンであることは知っていますが、私の経験ではアンチパターンになります。

IBallとIBoardには、それらがどのように相互作用するかについてのロジックはありません。 それは彼らがメソッドを持っていないことを意味しますか? それらのメソッドは、プライベートデータの単なるゲッターとセッターですか? IBallとIBoardが単なる構造体(またはそれらに相当するもの)である場合、それらはインターフェイスである必要はありません。 IBallやIBoardに送信できるメッセージの種類について説明するために、説明を具体化しますか?

_
2)(一般的に)ロジックはオブジェクト/データから分離すべきですか?
_

時々。 プレーンな古いデータがある場合は、ロジックをプレーンなデータから分離するのが適切です。 もちろん、あなたはもうOOPをしていません-手続き型コードを書いています。 動作をBallにハードコーディングしないという欲求に苦しんでいると思います。 おそらく、他のエンティティがボールの相互作用を決定する責任があるはずですが、その決定にボールが参加する余地がまだあります。 これは、戦略パターン(他のパターンの中でも)が作用する場所です。 現実の世界で物事がどのように機能するかを考えてください-物理的なボールと物理的なボードはどのように相互作用を調整しますか? 彼らが互いに話し合ったら、彼らは何と言うでしょうか? それをコードに実装できるかどうかを確認してください。

最後に、デザインについて一言。 「デザインを正しくする」ことは良いことだと思います。一方、それがhttp://www.joelonsoftware.com/items/2008/05/01.html[architecture astronaut]になるための道です。 現在コードベースにどんな問題があるのか​​考えてください。

  • リファクタリングは難しいですか?

  • 新しいタイプのものを追加するのは難しいですか?

  • 「ハードワイヤード」されすぎていますか?

デザインは真空の中に存在するのではなく、世界の現在の状態によって通知されます。 人々が思いつくクレイジーな携帯電話のコンセプトアートをいくつか見てください。悪いデザインの良い例を見るでしょう。 携帯電話は現在の技術によって制限されており、現実世界の制限を無視するデザインは夢に過ぎません。 ソフトウェアでも同じことが言えます。 コードがあなたにそれが必要だと伝えているものに注意を払ってください、そうすればうまくいくでしょう。

作成するソフトウェア(および完成するソフトウェア)が多いほど、経験が増え、美的感覚が向上します。 「間違ったことをする」ことを恐れて、ソフトウェアの完成を妨げないでください。 頑張って、機能させてから、プロセスから学んだことを確認してください。

1


タイトルとURLをコピーしました