2人のユーザーがプレイする（または1人のユーザーが白と黒の両方をプレイする）オフラインのAIなしGUI同期コマンドラインチェスゲームを作成しようとしています。つまり、スレッドは1つだけです。
チェスゲームには、特別な動きが含まれています{キャプチャ、アンパッサン、プロモーション、キャスリング、チェックメイト、膠着状態}
ユーザーは、開始位置と終了位置を指定してゲームを操作します。例：e1g1。それだけです。
私はオブジェクト指向デザインの特権を最大限に活用しようとしています。しかし、この要件のためだけに。状態パターンを実装する価値はありますか？ユーザーはコマンドを入力するだけなので、ゲームはユーザーにコマンドの後に他の決定をするように求めてはなりません。
編集：これを明確にしないことをお詫びします。私が混乱したのは、この画像のようなゲームコントロールレベルで状態を実装するか、この画像
のようなゲームピースレベルで状態を実装するかです。
後でゲームを改善したり、ゲームに機能を追加したりする予定がない場合は、ステートフルにする必要はありません。
ただし、将来の作業の可能性（1％程度）がある場合は、ステートフルにすることをお勧めします。不必要なコードを書くことは、新しいコンテキストで機能を書き直すよりも常に簡単だからです。
状態を使用すると、本格的なUIアプリケーションを使用する場合と同じように、cosnosleアプリケーションのチェスゲームにメリットがあります。主な利点は、あなたが言ったように、許可された動きとゲームの状態を追跡できることです：キャスリング、アンパッサン、チェック、チェックメイトなど。
ゲームの状態と可能な動きは、コンソールアプリケーション、UI、分散Webアプリケーションなどを使用しているという事実に影響されません。それらはゲームの内部ロジックと関係があります。
編集：
UIチェスアプリケーションで考えられるボーナスの1つは、セラチン状態の外観を特殊化する場合です。たとえば、チェック状態があるときにキングに赤い四角を配置します。