Boardクラスには8x82D配列のPiecesがあるので、board.move(piece1, 3, left)たとえば、Boardクラスでピースを移動することはできますが、その方法がないため、ピースを移動するように単純に指示するpiece1.move(3, left)方法はありません。ボードについて何かを知るため（パラメーターとして渡す以外）、特定のインデックスに移動できなかったか、ピースがすでにこのインデックスを占有しているかどうか、または境界外に移動するように指示されているかどうかを知ることができます。アレイの。
2 に答える
3
Gameaや。など、まだモデル化されていない他のオブジェクトがありますPlayer。一歩下がって、これらの各モデルの責任について考えてみましょう。
- ピース：A
Pieceはかなり最小限です。それはそれが何であるか、それがどの色であるかを知っています、それはおそらくそれについてです。 - ボード：また、かなり最小限です。それはその正方形が何であるかを知っています。
- ゲーム：これはおそらく最も複雑なコンポーネントです。それはゲームのルールを知っています。（結局のところ、ゲームのルールを変更したい場合は、
Boardまたはを変更する必要はありませんよね？）それは完全なゲームセットを構成するPieceものを知っています。Piecesそれぞれがどのような動きをすることができるかを知っていPieceます。Pieceそれは、与えられたものがいつでもどこにあるかを知っていBoardます。 - プレーヤー：
Playerと対話しGameます。Gameに対して特定のアクションを実行する必要があることを通知しPieceます。はそのGameアクションを許可または拒否し、そのアクションに基づいてGame（チェック、メイト、ステイルメイト、他のターンなど）の状態を変更します。Player（繰り返しますが、PiecesとはBoardこれらの状態を気にしません。）
オブジェクトGameが肥大化して扱いにくくなると、おそらくバラバラになり、ほとんどが複合オブジェクトとして存在する可能性があります。MoveListたとえば、特定のルールセットに対して可能な移動を行うことができます。はそれGameで構成されていますが、内部に含める必要はありません。
考えれば考えるほど、このドメインでは本当に「ダム」オブジェクトとして区別されているBoardと思います。Pieceそれらは実際にはエンティティではなく、単なる値オブジェクトです。別のピースとまったく同じ属性を持つ1つのピースは、本質的に他のピースと交換可能です。（Black Bishopを失った場合は、別のBlack Bishopに置き換えることができ、エクスペリエンスに悪影響を与えることはありません。）これら2つをモデルではなく不変のデータ構造として扱うと、ドメインがより流動的に機能する可能性があります。
（これは、まったく異なるsのセットを持つBoard他のユーザーが同じものを再利用できることにも注意してください。）GamesPiece
演習として、RobertMartinのボウリングゲームKataをフォローすることをお勧めします。ドメインを検証するための実際のテストを検討すると、ゲームドメインのモデリングにどれだけの労力を費やすことができれば、それがはるかに単純になることに驚くでしょう。私たちは一日中これらのチェスモデルについて学術的に考えることができますが、ゲームを検証するためのいくつかのテストを考え出すことで、より単純なデザインを生み出すことができます。
于 2012-10-01T00:28:01.173 に答える
2
作品自体は、それがどこに配置されているかについては何も知りません（そしておそらく知る必要はありません）。Boardしたがって、ピースを移動するためにメソッドを呼び出す必要があることには何の問題もありません。
于 2012-10-01T00:20:06.760 に答える