>>284
>>282じゃないが将棋は手の評価ロジック自体が本体であり全てみたいな感じだからOOPに向いてないと思うよ
OOPL前提で書くにしても駒に合法手の問い合わせなんかしない、盤面も移動範囲も整数配列でいい
以前遊びで組んだのはこんな感じだった

思考モジュール
※ルールと棋譜DB盤面テーブルなどをコンポジットしたクラス
・盤面テーブル =11×11の整数2次元配列+手駒リスト
→※駒の種別や盤外、効きの有無、成り、どちらの駒か等全てここにビットフラグで持つ
→9×9でないのは外周を外周を示す駒で埋める事で外周かどうかの判定を省くため
・ルール判定各種
→※局面によってルールの適用の要不要があるのでそれぞれ独立して持つ
→・駒の移動範囲テーブル
→・各種禁じ手判定など
・棋譜DB
→・定石を抽出して探索の枝切りや手抜きに使う
・評価関数
→※思考の本体であり盤面テーブルから次の手を探索する
→・ルール、DB、盤面テーブルは全てここで使う
・探索ツリー
→評価関数が吐き出した結果の保持用
→手番ごとに1から探すのは無駄なので探索結果はツリーの状態で保持

UI(表示)モジュール
※こいつらは表示専用でルールや思考ロジックには感知しない
・駒クラス
・盤クラス
・駒台クラス
など

UI側はともかく思考側は細かくクラス分けするメリットは殆ど感じられない、OOPの例題としては向いてないと思うんだ
これが実装中にルールに仕様変更の入るボードゲームなら話は多少違うだろうが…