State
注文ステータスの遷移
状態ごとに振る舞いを変える
このデモで分かること: 今の状態で「次に許す操作」を決める
このデモで State を使う理由
- 注文は「今どの状態か」で、次に許される操作が変わる。
- 許可遷移をあちこちに if で書くと、状態が増えるほど矛盾や抜けが起きやすい。
- State なら「今の状態が、自分からどこへ行けるか」を一箇所にまとめられる。
パターンなし vs このパターン（イメージ）
記事の本編ではなく、このデモ題材を if の山にした場合との対比です（疑似コード）。
パターンなし
// パターンなし（イメージ）
if (status == NEW && action == SHIP) { /* ？ */ }
if (status == PAID && action == PAY) { /* ？ */ }
// → 許可表がコード全体に散らばる
State あり
// State
if (status.canTransitionTo(next)) {
status = next;
}
// → 許可は OrderStatus が知っている
デモ
新規
セッション内の注文オブジェクトを保持しています。
このデモで使っている主な型
OrderStatus · Order
操作 → 動いたクラス / メソッド
- 操作: 現在の注文状態を表示（セッション内の Order）
- → Order.getStatus() → NEW（新規）
- → OrderStatus.allowedTargets() … 次に押せるボタンの元データ
- → 許可: PAID, CANCELLED
許可された遷移
全状態: 新規 · 支払済 · 発送済 · キャンセル
このパターンの解説記事 ↗
記事は考え方・別サンプルの解説です。このページのデモ実装とはソースが異なります （クラス名・題材はデモ用に簡略化しています）。