MOE3: Order モデル検討

Order と派生モデル

単一テーブル継承を使用するので、Order モデルだけではなく派生クラスで必要になる属性も先に考えておかなければならない。

必要になってから属性を追加するのがアジャイル流かもしれないが、明らかに必要になると分かっているものを先送りにするのはストレスなので。

ひとつひとつ見ていこう。

Order（命令）モデル

全ての命令の基底クラスとなり、Order インスタンスが生成されることはない。

Order モデルの属性

• player_id: 「誰が指示した命令か」を特定するための参照。
• unit_id: 「どの卓の何ターン目のどの軍への命令か」を特定するための参照。
• type: 単一テーブル継承用の属性。

HoldOrder（維持命令）モデル

何もしない命令。必要な属性は Order と同じはず。

だったら Order は捨てて HoldOrder を基底クラスにすればいいじゃん、という考えもないではないが、HoldOrder を特別扱いする合理的な理由がないのでこれで良い。

MoveOrder（移動命令）モデル

攻撃命令でもある。移動を伴うので「どこからどこへ」という情報が必要になる。

「どこから」は命令対象の軍が持っているが、「どこへ」は MoveOrder の固有の属性として持つ必要がある。

MoveOrder モデルで必要な属性

• destination_id: 「どこへ移動するか」を示す Province への参照。

「どこから」については MoveOrder#source メソッドを書こう。

しかし行軍解決処理で多用するであろうことを考えると、MoveOrder#source はともかく MoveOrder#destination は好みで言えばメソッド名としてちょっと長い。

いっそのこと MoveOrder#src MoveOrder#dst にしてしまうか。要検討。

SupportOrder（支援命令）モデル

支援対象についての情報を持つ必要がある。

実際には軍だけではなく、その軍が受ける命令まで含めて指定する必要があるので、支援命令の対象となるのは軍そのものではなく、その軍が受けた命令となる。

SupportOrder モデルで必要な属性

• target_id: 「どの命令を支援するか」を示す Order への参照。

支援の成立と不成立

支援命令の対象となるのは、維持命令か移動命令のみ。

他国軍の維持を支援する場合、実際の支援対象が維持命令、支援命令、輸送命令のいずれであっても支援は成立するが、移動を支援するのであればその移動先が一致しなければならない。

• 維持・支援・輸送命令に対する維持支援はすべて成立する。
• 維持・支援・輸送命令に対する移動支援は成立しない。
• 移動命令に対する維持支援は成立しない。
• 移動先の異なる移動支援は成立しない。
• 結果的に失敗した移動命令に対する維持支援は成立しない。

ConvoyOrder（輸送命令）モデル

輸送対象についての情報を持つ必要がある。

こちらも正確を期すのであれば「どの軍の移動命令を輸送するか」と表現するのが正しい。日本語的には微妙だが気にしない。

target 属性については SupportOrder と共有できるだろう。

輸送の成立と不成立

輸送命令の対象となるのは移動命令、厳密には Coast から Coast への陸軍の移動命令のみ。

移動支援と同様に、移動先が一致しなければ輸送は成立しない。

• 輸送対象に移動命令以外を指定することはできない。
• 輸送対象となる移動命令は陸軍の Coast から Coast への移動のみ。
• 移動先の異なる輸送は成立しない。

Order モデルの属性

いったんまとめ。

Order モデルの属性

• player_id: 「誰が指示した命令か」を特定するための参照。
• unit_id: 「どの卓の何ターン目のどの軍への命令か」を特定するための参照。
• destination_id: 「どこへ移動するか」を示す Province への参照。
• target_id: 「どの命令を」支援あるいは輸送するかを示す Order への参照。
• type: 単一テーブル継承用の属性。

実は、これではまだ足りない。

仮想命令についてもう少し練り込む必要がある。

その他の命令

撤退フェイズの撤退命令と解隊命令、調整フェイズの増設命令と解隊命令を Order の派生クラスにするかどうかは検討中。