Blueprint

In this design, the Order class itself holds all the rules for the order's lifecycle. It stores the state as a plain string and moves between states with a big switch block. The code is stiff, and each update can break something that used to work (a regression).

1. Understanding the Issue

In an e-commerce or delivery domain, an Order moves through a fixed lifecycle (e.g., placed, preparing, shipping, delivered). Each phase has its own rules about which actions are allowed (such as canceling an order) and which phase comes next.

Instead of giving each phase its own class, the Order class manages every rule for every state. The state logic gets mixed into the order's ordinary methods.

2. Issues In The Code

Cumbersome State Transition Management

The Issue: The steps from one state to the next are written inside the nextState() method as a switch on text values.
The Impact: To add a new stage or change the order of steps, you must open up this central method. That can break the transitions that already work.

Lack of Encapsulation & SRP Violation

The Issue: The Order class stores the order's data and also holds the rules for every phase (like checking, for each status, whether cancelling is allowed).
The Impact: This violates the Single Responsibility Principle (SRP), which says a class should have one reason to change. Here the class has two. It changes when the stored order data changes, and again whenever a workflow rule changes.

Code Duplication Risks

The Issue: The state checks are spread over separate methods like cancelOrder() and nextState().
The Impact: Each new action (such as refundOrder(), holdOrder(), or returnOrder()) will need the same multi-branch checks again. The copies drift apart, and fixing one can leave the others wrong.

Missing Flexibility for Future Changes

The Issue: The class depends on magic strings ("ORDER_PLACED", "PREPARING"), which are plain text values with no checking.
The Impact: A typo is not caught when the code is compiled. It only shows up when the program runs, if at all. A misspelled state simply fails every comparison without any error, so growing the system is risky.

3. Structural Vulnerabilities

Operational Metric	Naive Design Status	Architectural Target
State Organization	Monolithic: Trapped inside big conditional blocks.	Isolated: Encapsulated in separate objects.
Extensibility	Rigid: Adding a state forces changes across multiple methods.	Flexible: Just add a new state class.
Validation Safety	Fragile: Controlled by magic strings that nothing checks.	Safe: Driven by typed objects, so mistakes show up at compile time.

4. Summary of the "Smell"

A "smell" is a sign in the code that something is off. Suppose an object behaves very differently depending on its condition, and its code is full of large conditional blocks that check a status field. That is a State Mutation Smell.

The State Design Pattern resolves this problem by creating a separate class for each lifecycle phase. The main entity passes each action to its current state object (delegating). The state checks turn into plain method calls, and the right class runs each one (polymorphism).

In this topic

Before code1 file

Before/Main.java77 linesGitHub

1package DesignPatterns.BehaviouralPatterns.StatePattern.Before;2import java.util.*;34/**5 * PROBLEM: Fragmented State Transition Mechanics.6 * The 'Order' class is acting as both the data entity and the controller for 7 * every single state rule. It breaks encapsulation principles by explicitly handling8 * string state flags across all of its operations.9 */10class Order {11    // ISSUE 1: MAGIC STRINGS AND RUNTIME FRAGILITY12    // State is managed via string literals. A single typo like "PREPAREING" 13    // will silently break state comparisons without raising compile-time errors.14    private String state;1516    public Order() {17        this.state = "ORDER_PLACED";18    }1920    /**21     * ISSUE 2: CONDITIONAL SCATTERING22     * For every single action (cancel, refund, ship, assign), you must write 23     * complex if-else conditions checking every permissible state permutation.24     */25    public void cancelOrder() {26        if (state.equals("ORDER_PLACED") || state.equals("PREPARING")) {27            state = "CANCELLED";28            System.out.println("Order has been cancelled.");29        } else {30            System.out.println("Cannot cancel the order now.");31        }32    }3334    /**35     * ISSUE 3: OCP VIOLATION & MONOLITHIC SWITCH BLOCKS36     * If you want to introduce a new intermediate state (e.g., "DISPATCHED" or "RETURNED"),37     * you have to modify the switch block here, the conditional loops in cancelOrder(), 38     * and every other state-dependent method. This opens up massive regression risks.39     */40    public void nextState() {41        switch (state) {42            case "ORDER_PLACED":43                state = "PREPARING";44                break;45            case "PREPARING":46                state = "OUT_FOR_DELIVERY";47                break;48            case "OUT_FOR_DELIVERY":49                state = "DELIVERED";50                break;51            default:52                System.out.println("No next state from: " + state);53                return;54        }55        System.out.println("Order moved to: " + state);56    }5758    public String getState() {59        return state;60    }61}6263class Main {64    public static void main(String[] args) {65        Order order = new Order();66        67        System.out.println("Initial State: " + order.getState());6869        order.nextState(); // ORDER_PLACED -> PREPARING70        order.nextState(); // PREPARING -> OUT_FOR_DELIVERY71        order.nextState(); // OUT_FOR_DELIVERY -> DELIVERED7273        order.cancelOrder(); // Validates delivery block7475        System.out.println("Final State: " + order.getState());76    }77}

Lifecycle Management & State Transitions