Javaのenumで注文の状態遷移を管理する｜出荷後のキャンセルを防ぐ

2026年11月4日

この記事でわかること

Javaのenumで注文の状態を表しても、setterから自由に書き換えられると、出荷済みをキャンセルできます。出荷とキャンセルを注文の操作にし、拒否した後も状態が変わらないことをJUnitで確かめます。

新人SE

出荷済みの注文なのに、管理画面からキャンセルできました。注文の状態はenumにしたのに、どこが足りなかったんでしょう。

ポンコツSE

「キャンセル済み」という値は使えます。次に、「今の状態からキャンセルできるか」を、注文を変更するときに確認しましょう。

注文管理画面のキャンセルボタンから、注文の状態を更新する処理を作ります。注文が未出荷なら、そのままキャンセルできます。すでに荷物を出荷した注文までキャンセル済みになると、倉庫では出荷済みなのに管理画面ではキャンセル済み、という食い違いが起きます。

対象は、Javaのクラスとenumを読める人です。まず自由に状態を指定できる例で問題を再現し、次に「出荷する」「キャンセルする」という操作を通してだけ状態を変える形へ直します。

実行サンプル

setter版と修正版、8件のJUnit、pom.xml、READMEを収録。JDK 17とMavenで、展開したディレクトリから mvn clean test を実行できます。

GitHubでコード全文を見る ZIPをダウンロード

出荷とキャンセルを許す状態を表にする

この例では、注文を作ると未出荷になります。未出荷からは出荷かキャンセルのどちらかを選べます。出荷済みとキャンセル済みになった後は、同じ操作の再送も含めて変更を拒否します。拒否した場合は、操作前の状態を維持します。

今の状態	出荷する	キャンセルする
未出荷	出荷済みになる	キャンセル済みになる
出荷済み	拒否し、出荷済みのまま	拒否し、出荷済みのまま
キャンセル済み	拒否し、キャンセル済みのまま	拒否し、キャンセル済みのまま

次がOrderStatus.javaの全文です。このenumが表すのは、注文が取り得る状態です。「いま何ができるか」は、表のように現在の状態と操作の組で決まります。

package example.order;

enum OrderStatus {
    UNSHIPPED,
    SHIPPED,
    CANCELLED
}

package example.order;

enum OrderStatus {
    UNSHIPPED,
    SHIPPED,
    CANCELLED
}

setterで、出荷済みがキャンセル済みに変わる

次は修正前のBrokenOrder.javaの全文です。setStatusへ渡せる状態はenumで定義した値ですが、現在の状態は確認していません。出荷処理がsetStatus(SHIPPED)を呼んだ後でも、管理画面の処理がsetStatus(CANCELLED)を呼ぶと、そのままキャンセル済みに変わります。

package example.order;

final class BrokenOrder {
    private OrderStatus status = OrderStatus.UNSHIPPED;

    OrderStatus status() {
        return status;
    }

    void setStatus(OrderStatus status) {
        this.status = status;
    }
}

package example.order;

final class BrokenOrder {
    private OrderStatus status = OrderStatus.UNSHIPPED;

    OrderStatus status() {
        return status;
    }

    void setStatus(OrderStatus status) {
        this.status = status;
    }
}

出荷画面と管理画面の両方にifを追加する方法もあります。その後でバッチからも注文を変えるとき、バッチでも同じ確認が必要になります。注文をどこから変更しても表の条件を守りたいので、注文の状態を書き換える処理へ確認を移します。

注文のshipとcancelに、変更前の状態確認を置く

修正版Order.javaでは、呼び出し側がship()かcancel()を選びます。どちらも注文の中で現在の状態を読み、未出荷のときだけ、操作ごとの次の状態を代入します。未出荷でなければIllegalStateExceptionを投げます。変更できない注文には代入まで進みません。

package example.order;

final class Order {
    private OrderStatus status = OrderStatus.UNSHIPPED;

    OrderStatus status() {
        return status;
    }

    void ship() {
        transitionFromUnshipped(OrderStatus.SHIPPED);
    }

    void cancel() {
        transitionFromUnshipped(OrderStatus.CANCELLED);
    }

    private void transitionFromUnshipped(OrderStatus next) {
        if (status != OrderStatus.UNSHIPPED) {
            throw new IllegalStateException("未出荷の注文だけを変更できます");
        }
        status = next;
    }
}

package example.order;

final class Order {
    private OrderStatus status = OrderStatus.UNSHIPPED;

    OrderStatus status() {
        return status;
    }

    void ship() {
        transitionFromUnshipped(OrderStatus.SHIPPED);
    }

    void cancel() {
        transitionFromUnshipped(OrderStatus.CANCELLED);
    }

    private void transitionFromUnshipped(OrderStatus next) {
        if (status != OrderStatus.UNSHIPPED) {
            throw new IllegalStateException("未出荷の注文だけを変更できます");
        }
        status = next;
    }
}

この例では出荷とキャンセルの前提がどちらも未出荷なので、同じprivateメソッドにしています。後から「出荷後の返品」を追加するなら、cancel()の条件を緩める前に、返品という操作が許される状態と、処理後の状態を表へ追加します。管理画面では呼び出した操作の結果を表示し、注文クラスは状態を変えてよいかを判断します。

外部から来た文字列をOrderStatusへ変換するときのエラーは別の段階です。まず入力が定義済みの値かを判断し、操作として許されるかはこの章の条件で判断します。

拒否時は、例外と変更前の状態を両方確かめる

配布ZIPを展開し、pom.xmlのある場所でmvn clean testを実行します。OrderTest.javaには、setter版の問題を観測する1件、修正版の初期状態1件、許可する2操作、拒否する4操作があります。通常は計8件が成功します。

OrderTest.javaの全文を見る

package example.order;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;

import static example.order.OrderStatus.CANCELLED;
import static example.order.OrderStatus.SHIPPED;
import static example.order.OrderStatus.UNSHIPPED;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

class OrderTest {
    @Test
    void setterLetsShippedOrdersBecomeCancelled() {
        BrokenOrder order = new BrokenOrder();
        order.setStatus(SHIPPED);

        order.setStatus(CANCELLED);

        assertEquals(CANCELLED, order.status());
    }

    @Test
    void startsAsUnshipped() {
        assertEquals(UNSHIPPED, new Order().status());
    }

    @Test
    void canShipAnUnshippedOrder() {
        Order order = new Order();

        order.ship();

        assertEquals(SHIPPED, order.status());
    }

    @Test
    void canCancelAnUnshippedOrder() {
        Order order = new Order();

        order.cancel();

        assertEquals(CANCELLED, order.status());
    }

    @ParameterizedTest(name = "{0}から{1}を拒否して、状態は変えない")
    @CsvSource({
            "SHIPPED, SHIP",
            "SHIPPED, CANCEL",
            "CANCELLED, SHIP",
            "CANCELLED, CANCEL"
    })
    void refusesForbiddenOperationsWithoutChangingStatus(OrderStatus initial, Action action) {
        Order order = new Order();
        if (initial == SHIPPED) {
            order.ship();
        } else {
            order.cancel();
        }

        assertThrows(IllegalStateException.class, () -> action.applyTo(order));
        assertEquals(initial, order.status());
    }

    private enum Action {
        SHIP, CANCEL;

        void applyTo(Order order) {
            switch (this) {
                case SHIP -> order.ship();
                case CANCEL -> order.cancel();
            }
        }
    }
}

package example.order;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;

import static example.order.OrderStatus.CANCELLED;
import static example.order.OrderStatus.SHIPPED;
import static example.order.OrderStatus.UNSHIPPED;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

class OrderTest {
    @Test
    void setterLetsShippedOrdersBecomeCancelled() {
        BrokenOrder order = new BrokenOrder();
        order.setStatus(SHIPPED);

        order.setStatus(CANCELLED);

        assertEquals(CANCELLED, order.status());
    }

    @Test
    void startsAsUnshipped() {
        assertEquals(UNSHIPPED, new Order().status());
    }

    @Test
    void canShipAnUnshippedOrder() {
        Order order = new Order();

        order.ship();

        assertEquals(SHIPPED, order.status());
    }

    @Test
    void canCancelAnUnshippedOrder() {
        Order order = new Order();

        order.cancel();

        assertEquals(CANCELLED, order.status());
    }

    @ParameterizedTest(name = "{0}から{1}を拒否して、状態は変えない")
    @CsvSource({
            "SHIPPED, SHIP",
            "SHIPPED, CANCEL",
            "CANCELLED, SHIP",
            "CANCELLED, CANCEL"
    })
    void refusesForbiddenOperationsWithoutChangingStatus(OrderStatus initial, Action action) {
        Order order = new Order();
        if (initial == SHIPPED) {
            order.ship();
        } else {
            order.cancel();
        }

        assertThrows(IllegalStateException.class, () -> action.applyTo(order));
        assertEquals(initial, order.status());
    }

    private enum Action {
        SHIP, CANCEL;

        void applyTo(Order order) {
            switch (this) {
                case SHIP -> order.ship();
                case CANCEL -> order.cancel();
            }
        }
    }
}

pom.xmlの全文を見る

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>example</groupId>
  <artifactId>java-enum-order-state-transition</artifactId>
  <version>1.0.0</version>
  <properties>
    <maven.compiler.release>17</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.12.2</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.14.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.5.3</version>
      </plugin>
    </plugins>
  </build>
</project>

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>example</groupId>
  <artifactId>java-enum-order-state-transition</artifactId>
  <version>1.0.0</version>
  <properties>
    <maven.compiler.release>17</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.12.2</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.14.1</version>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.5.3</version>
      </plugin>
    </plugins>
  </build>
</project>

拒否する4ケースは、まずテストでship()かcancel()を呼び、注文を表の開始状態にします。次に禁止操作を呼び、assertThrowsで例外を確認します。その直後にassertEqualsで状態を読み直すのは、例外を投げる前に状態を書き換えてしまう実装を見つけるためです。

確認として、実装から状態チェックを外したところ、禁止操作の4件が失敗しました。次に、変更前の状態を見て例外を投げる処理は残し、代入だけ先にすると、別の状態に移る2件が失敗しました。この2件は例外自体が出るので、状態も比べるテストで検出できます。

ルールを変えるときは、どの操作を追加するか決める

レビューでsetStatusを見つけたら、「ここでは出荷後にキャンセルできません。更新先だけ渡すと今の状態を見ずに変更できるため、cancel()に置き換え、出荷済みのまま残ることもテストできますか？」と確認します。出荷とキャンセルの条件が将来分かれたら、それぞれの操作で確認する形に戻しても、呼び出し側の名前はそのままです。

状態だけを直接書き換える入口を呼び出し側に渡していない。
今の状態、操作、成功後の状態を表で確認できる。
禁止操作と同じ操作の再送で、変更前の状態を確認した。
データベースで出荷とキャンセルが同時に走るなら、競合を防ぐ更新方法を別に確認する。

状態のルールを、別の業務でも置き分けるなら

状態の書き換えが複数の画面や処理に散ってきたときは、『改訂新版良いコード／悪いコードで学ぶ設計入門』で、値と処理をどうまとめるかを掘り下げられます。今回の例を動かした後なら、自分のコードで状態を変更する入口と、その変更を判断するコードを探すところから始められます。

PR Java新人・若手向け

改訂新版良いコード／悪いコードで学ぶ設計入門

仙塲大也 (著)

レビューで直される理由を、Javaの具体例から理解する。

命名、責務、クラス設計、不変性などを良い例と悪い例で比較できます。現場のコードレビューと結びつけやすい一冊です。

設計の悪さを具体例から学びたい
レビュー指摘の判断軸を増やしたい

Amazonで詳細を見る

当サイトはAmazonアソシエイト・プログラムの参加者です。価格・在庫・配送条件はAmazonでご確認ください。

まとめ

enumで注文の状態を表し、ship()とcancel()で状態の変更を扱います。この例では、未出荷のときだけ変更を許し、違反したら例外を投げ、状態は変えません。新しい操作を増やすときは、現在の状態と操作の表を見て、許す組と拒否した後の状態をJUnitへ書きます。

-設計・テスト・レビュー
-enum, Java, JUnit, クラス設計

設計・テスト・レビュー

2026/11/5

Javaのリファクタリング前に書くJUnit｜仕様書にない既存動作を残す

この記事でわかること仕様書にない既存動作を調べ、残すべき戻り値をJUnitで確かめる手順です。Javaの配送判定を、整理する前、整理した後、新しい仕様を入れた後の3段階で比較します。保守チームに「離島の注文は発送前に人が確認する」という依頼が来ました。配送判定のクラスにはすでに、発送できない品目を止める処理と、住所が不足した注文を保留する処理が混ざっています。担当を分ければ離島の条件は追加しやすくなります。順番を入れ替えただけで、発送禁止の品が確認待ちに流れると困ります。仕様書には「配送できない場合は ...

設計・テスト・レビュー

2026/11/4

MicrosoftのMSSQLで特定の構成の場合はフェールオーバーができないの要注意

このページに書いてあること SQL Serverのピアツーピア（P2P）レプリケーション構成で、アプリのDB接続先をどう切り替えるかを調べた記録です。データを複製する構成と、障害時に接続先を切り替える構成を分けて確認します。前提 Webアプリから複数のSQL Serverインスタンスへ接続できる構成を想定します。図は当時検討した構成例です。実環境の確認では、SQL Server・接続ドライバーのバージョン、DBの冗長方式、接続文字列を控えます。問題と解決当時のP2P構成では、接続文字列に failo ...

設計・テスト・レビュー

2026/11/4

改修のテストはどこまでやる？単体・結合・手動の範囲を決める例

「単体テストは通った。でも、画面やDBまで全部試すべき？」改修のたびに、どこまで確認すればよいか迷うことがあります。先に結論見つけたい失敗から、確認する範囲を選ぶ。変更した行数やケース数だけで決めない。実物とモックを明記する。「単体・結合」は確認する範囲、「手動」は実施方法として分ける。未確認のリスクも残す。省く確認は、判断する人と補う方法をセットで相談する。この記事では、架空の問い合わせ管理を使い、入力・権限・検索の3つの改修からテスト範囲を考えます。確認を省くときの伝え方も、記入例で示します ...

設計・テスト・レビュー

2026/11/4

Spring BootのControllerでやってはいけないこと

AIによる要約ControllerはURLから注文IDを受け取り、Serviceへ渡し、結果をJSONとHTTPステータスに変えます。注文取消で、入口での400、業務結果に基づく404と409、成功の200を見分けます。注文100は出荷待ち、101は出荷済み、102は取消済みです。URLのIDが文字列で数値にできない場合と、数値だが取消できない場合は、同じ失敗でも処理が止まる場所が違います。同じ注文取消の例で、Controllerに残す条件とServiceへ移す条件を分けます。この記事のポイント U ...

設計・テスト・レビュー

2026/11/4

Javaの現在日時をテストで固定する方法｜Clock.fixedで期限判定を確認する

「昨日まで通った期限判定テストが、今日になったら落ちた」。期限を固定して期待結果だけ書き、判定の中でLocalDate.now()を呼んでいると起こる失敗です。テストのたびに予定日を書き換える運用では、期限当日と翌日の境界を保証できません。ここで取る方針は、現在日時を業務ロジックの入力として扱い、Clockを渡すことです。題材は「締切日当日まで申請でき、翌日からできない」という架空の申請機能。画面表示やDB保存ではなく、期限判定を毎日同じ条件で確かめます。実行サンプル締切日の当日・翌日と、同じ瞬間を ...

JUnitの@TempDirで上書きをテストする｜出力に失敗しても既存ファイルを残す

Javaのenumで注文の状態遷移を管理する｜出荷後のキャンセルを防ぐ

出荷とキャンセルを許す状態を表にする

setterで、出荷済みがキャンセル済みに変わる

注文のshipとcancelに、変更前の状態確認を置く

拒否時は、例外と変更前の状態を両方確かめる

ルールを変えるときは、どの操作を追加するか決める

状態のルールを、別の業務でも置き分けるなら

改訂新版 良いコード／悪いコードで学ぶ設計入門

この記事とあわせて読みたい

まとめ

改訂新版良いコード／悪いコードで学ぶ設計入門