2011-08-05 2 views
6

私はJavaでチェスゲームをデザインしています(AIはなく、ユーザーが制御します)、まだOOPに慣れています。私には2つの質問があります。Javaでチェスゲームのオブジェクトを設計する

私はGameCellPieceBoardオブジェクト、Playerオブジェクトに加えて、持つことを考えていました。

私の質問は本当に必要なのですか?もちろん、私はする必要はありませんが、いずれかのオプションは、より良いデザインと考えられていますか?一方では、Playerはプレーヤーの部分に関する情報を格納するのに便利であり、takeTurn()などのメソッドを含める必要があります。 (私の実装では、可能なすべての動きを把握したいので、メソッドgetAllMoves()を使用します)。一方、Playerは単に既存のデータを再編成したものではありませんか?各ピースには、既にどのプレイヤーが所属しているかの表示があります。私のゲームにはAIが含まれていないので、ではなく、Gameに属することが考えられます。再び最初の手では、おそらくPlayerは、そのデータを使用しますが処理を実行しない方法getAllMoves()しか持てません。

最初の質問に対する回答が「はい」の場合に関連する2番目の質問は、どのようにオブジェクト間の関係を整理するかです。 getAllMoves()はセルの配列を入力として取り込みます。 Playerクラスは、そのセルが入力として渡されたセルの一部であるという事実に依存するということは奇妙に感じられます。プレーヤーごとに分割されたセルのデータがボード内のすべてのセルの配列と一緒に保持され、一緒に更新されて、それらが合意することを保証すれば、それはより良いと感じるでしょう。もちろん、彼らが同意するという保証はどちらかの方法で存在しますが、PlayerオブジェクトはBoardオブジェクトで行われる保証について認識してはいけません。

どのようにこれらの質問に対処しますか?

ありがとうございます!

+1

[BDUF](http://en.wikipedia.org/wiki/Big_Design_Up_Front)を試しているように聞こえます。[TDD]のようなオブジェクトモデルを駆使する別の方法が考えられますhttp://msdn.microsoft.com/en-us/magazine/dd882516.aspx) – razlebe

+1

私はチェスのようなゲームをデザインすることは、OOPに慣れるための非常に良いアプローチだと思います。直下のサブクラスとのインタフェースによってアソシエーションを好むことを忘れないでください。 –

答えて

2

Playerオブジェクトを持つIMHOは良いデザインです。
後でAIPlayerとHumanPlayerを実装しているインターフェースでも、それを洗練することさえできます。
今日はgetAllMovesメソッドだけが必要ですが、後でもっと必要な場合があります。オブジェクトを持っていると、プレイヤーの操作性を向上させるのに役立ちます。

2番目の点として、Playerが直接getAllMoves()メソッドを実装するかどうかはわかりません。

私はそれをChessGameオブジェクトに委譲しました。プレイヤーは、この場合には、ゲームや代表者getAllMovesはこのように、このゲームのインスタンスを呼び出すへの参照を持っています:

擬似コード:)

ちょっとゲーム、この作品のために利用できる移動何ですか?

+0

私は同意します。 Player内でgetAllMovesを使用すると、それを全知にします。このアプローチが1つのクラスの中にたくさんの論理を積み重ねることにつながるリスクがあります。実生活では、プレーヤーはボードを見ることによって可能な動きを評価するものとして見ることができます。これはあなたが与えた擬似コードを反映したメッセージとして転置することができます。 –

+0

ありがとう!私はプレーヤーがゲームを参照してはならないと思っていたが、それは意味があると思う。私が立ち上がっている別の場所はピースです。それは、異なる作品のために利用可能な異なる動きのロジックを格納する必要があるようだ - その理由は、私は各作品の種類のクラスを作成した。しかし、もう一度、それが動くことができるかどうかを判断するには、周囲の細胞について知っていなければなりません。それはゲームや作品がすべきことですか? – user64480

+0

@ user880129、これは自分自身にこの質問をするのは本当に良いことですが、私はこの種の配慮を失っています。ときどきOOP私たちはあまりにも多くのことを考えさせる:)あなたのケースでは、私はハブとして動作し、すべてのゲームの状態に関連する質問に答えることができる中央クラスを作成します:このセルは無料です、周りの作品です、これは移動はボードの外にあるので、その部分には移動の説明と小さなロジックしか含まれません。たぶんあなたはそれがどのように行われているかを見るためにオープンソースのチェスゲームを見つけようとするべきです。これはあなた自身のシステムを構築するのに役立ちます。 – Guillaume

1

「プレイヤー」オブジェクトが必要かどうかは、このオブジェクトがシステム内の他のオブジェクトと相互作用しているかどうかを確認してください。また、記録したいデータや状態情報はありますか?私はあなたがプレイヤーに関連して追跡したいと思うかもしれない2つの事柄を考えることができます - 捕捉されたもの、おそらくポイントスコア。

ところで、オブジェクトが互いにどのように関係しているかを視覚化するために、オブジェクトモデルを構築することをお勧めします。これにより、オブジェクト間のインターフェースと必要なメソッドの優れたアイデアも得られます。

+2

...プレイヤー名、再生色 –

1

あなたはUML、特にユースケースとシーケンス図をよく知っていますか?これはモデル化の演習のように聞こえ、ドメインモデルの概念を調べることも良い考えです。

Playerのような使用ケースのアクターは、通常、クラス(別名代用品)として転置されます。他のクラスは、一方のActorクラスともう一方のグローバルSystemクラスを使用して各ユースケースの概略シーケンス図から始めることで判断できます。

このシステムクラスは、さまざまなメッセージを表示するにつれて徐々に分解されます。メソッド/メッセージがクラスの単一のインスタンスに直接的でなく、属性/内部​​状態である場合は、他の場所に属する可能性があります(例:BankAccountクラスはBankAccountManagerクラスと同じ責任を持ちません)。あなたは性質に応じてメソッドをグループ化することができ、他のいくつかのクラスが表示されるはずです。

そこから、それらの間に1対1、1対多および多対多の関係が存在するかどうかを判断する単純なケースであるはずです。 Javaでは、これらは単一のインスタンスまたはリストと方向性(クラスAはクラスBについて知っていますか一方向の通りですか?)によって表され、それぞれのクラス内の参照の有無によって表されます。

P.S:私が大まかに説明しているのは、方法論のアプローチであり、UMLは内容自体が異なるビューからシステムを記述するだけであることに注意してください。

関連する問題