導入
ゲームのロジックを管理するクラスは、
状態遷移、ルール、オブジェクト管理などが混在しやすく、
分岐の増加とともに急速に複雑化する。
特に、状態ごとに処理が大きく変わる場合、
ifやswitchによる分岐が肥大化し、見通しが悪くなる。
それに分岐で解決しようとすると破綻する種類の問題がある。
例えば、状態ごとに異なる更新処理・入力処理・遷移条件が絡み合う場合、
分岐は状態数に対して指数的に増加し、局所的な修正が全体に影響する構造になる。
本パターンは、この問題を解決するために設計された。
理想から設計したものではなく、実装上の課題を解決する過程で自然に構築されたものである。
結果として、特定の言語に依存しない汎用的な構造となっている。
コンセプト
本パターンは、現実の競技における「フィールド」「審判」「ルール」「主催者」といった役割構造をモデルとしている。
状態遷移を中心としながらも、
データ（Field）と処理（Rule）と制御（Judge）を分離し、
それらを構造として統合したものである。
構成要素
本パターンは以下の5つの要素で構成される。
フィールド（Field）
審判（Judge）
アクションルール（Action Rule）
コンディションルール（Condition Rule）
雇い主（Employer）
全体の流れ
まず、ゲームの状態を保持するフィールドが存在する。
審判はそのフィールドとルールを用いてゲーム進行を行う。
フィールドが持つステートに応じてルールが適用され、
ステート内で実行される処理（アクションルール）
別のステートへ遷移するかの判断（コンディションルール）
が分離されている。
審判は雇い主によって管理され、フィールドとルールを受け取って処理を実行する。
各要素の説明
フィールド
フィールドは、ルールで使用される変数をまとめたコンテナである。
審判が持つすべてのルールに対して共通のコンテキストとして機能する。
現在のステートをもっている。このステートの分け方は状態単位だけでなく、機能単位や画面単位でもよい。
本パターンにおけるステートは、単なる状態遷移ではなく、
「振る舞いを切り替えるための文脈」として扱う。
ステートの分け方は用途に依存するが、「振る舞いが明確に変わる単位」で区切ると扱いやすい
これにより、キャラクターの状態だけでなく、
機能単位や画面単位などにも適用可能となる。
また、単なるデータの集合ではなく、変数同士の関係性を保ったまま管理する役割を持つ。
審判
審判は、フィールドとルールを束ねるコンテナであり、状態遷移の進行を担う。
ルールを適用し、ステートの変更を統制する唯一の存在である。
すべての状態遷移は必ず審判を経由することで、
遷移の一貫性と検証可能性が保証される。
アクションルール
ステート内で実行される処理を定義する。
状態が維持されている間の振る舞いや、遷移時の処理を担う。
コンディションルール
ステート遷移を行うかどうかを判断する。
条件を満たした場合、次のステートを返す。
雇い主
雇い主はフィールドとルールの所有者であり、審判を管理する。
複数の審判を保持可能
審判の実行タイミングを制御する（スケジューラ）
これにより、状態遷移の制御と時間的な実行管理が分離される。
雇い主は、外部システム（ゲームループや入力、時間管理など）と
状態遷移システムを接続する役割も担う
一言でまとめると
本パターンの本質は、「状態遷移の判断・処理・データを分離し、それを審判が統制する構造」にある。
注意点
・雇い主によるフィールドの直接変更は行わない
・ループ中に状態遷移が発生する設計は慎重に扱う（実行単位を明確にする）
・ルール間で暗黙的な依存関係を作らない（例：あるルールの実行を前提に別のルールを書くなど）
この制約を破ると、状態遷移の独立性が失われ、設計全体が密結合になる。
・フィールドに自身を管理する雇い主と審判を持たない
適用が有効なケース
・状態によって処理が大きく変わる場合
・ifやswitchによる分岐が増え続けている場合
・ルールをエディタなど外部から管理したい場合
似てるデザインパターン
本パターンは完全に新規の発明というより、
既存の設計パターンの要素を組み合わせ、再構成したものに近い。
1. Stateパターン
共通点
状態遷移が中心
状態ごとに処理が分かれる
違い
State：状態自身がロジックを持つ
雇われ審判：ロジックはRuleに分離される
2. Finite State Machine（FSM）
共通点
構造がほぼ一致
状態
遷移条件
遷移時処理
違い
FSM：テーブル or 分岐で実装されることが多い
本パターン：オブジェクトとして分離
3. Strategyパターン
共通点
処理をインターフェースで分離
差し替え可能
違い
Strategy：単一のアルゴリズム
本パターン：状態ごとに複数のルール
4. Mediatorパターン
共通点
Judgeが中央で制御
直接依存を排除
違い
Mediatorはオブジェクト間の通信を仲介するのに対し、
本パターンのJudgeは「状態遷移そのものの意思決定」を担う
5. Observerパターン
状態変化を監視する
共通点
外部（Employer）が状態を監視可能
違い
Observerは状態変化を通知する（Push型）のに対し、
本パターンでは雇い主が任意のタイミングで状態を参照する（Pull型）。
6. Commandパターン
共通点
ActionRuleが処理単位になっている
最後に
本パターンは、特定の用途に特化したものではなく、
構造を変えずに様々な文脈へ適用できる点に特徴がある。
そのため、一度理解すれば、
同じ設計思想で複数の問題を扱うことができる。
これは、拡張ではなく運用によって広がる設計である。
また、状態・ルール・データを分離したうえで統合しているため、
構造としての見通しを保ちながらスケールさせやすい。