How to handle Order status changes with State Design Pattern

Question

Currently, I'm working on the Order Microservice, where I have two methods related to order status changes store(Order order) and updateStatus(int orderId, String status), I'll explain later.

There are four states of the Order:

Waiting -> Expired

Waiting -> Canceled

Waiting -> Purchased

Purchased -> Canceled

I've provided the state flow diagram below, to make it clear (hopefully)

When the order created then the status will be "Waiting", if the user has paid it then the status becomes "Purchased", if the buyer or product owner cancel it then the status becomes "Canceled", and if the time exceeded then the status becomes "Expired".

For every microservice I want to work on, I'll be implementing Gang Of Four design pattern if possible, and for the order status I decided to implement state design pattern since it is related and from what I refer in many blogs, like in the document status stuff (DRAFT, ON REVIEW, etc), audio player stuff (PAUSED, PLAYED, etc) and so on.

This is what I've done:

Base State

public interface OrderStatus {
    void updateStatus(OrderContext orderContext);
}

Waiting state

public class WaitingState implements OrderStatus {
    // omited for brevity    
    
    @Override
    public void updateStatus(OrderContext orderContext) {
        orderContext.getOrder().setStatus("Waiting");
    }
}

Purchased State

public class PurchasedState implements OrderStatus {
    // omited for brevity

    @Override
    public void updateStatus(OrderContext orderContext) {
        orderContext.getOrder().setStatus("Purchased");
    }
}

Other states

..

Context:

public class OrderContext {
    private OrderStatus currentStatus;
    private Order order;

    public OrderContext(OrderStatus currentStatus, Order order) {
        this.currentStatus = currentStatus;
        this.order = order;
    }

    public void updateState() {
        currentStatus.updateStatus(this);
    }

    public OrderStatus getCurrentStatus() {
        return currentStatus;
    }

    public void setCurrentStatus(OrderStatus currentStatus) {
        this.currentStatus = currentStatus;
    }

    public Order getOrder() {
        return order;
    }

    public void setOrder(Order order) {
        this.order = order;
    }
}

The client is the OrderServiceImpl which I called from OrderController.

public class OrderServiceImpl implements OrderService {
    // omited for brevity
    
    @Override
    public Order store(Order order) {
        WaitingState state = WaitingState.getInstance();
        OrderContext context = new OrderContext(state, order);
        context.updateState();
    
        // do other stuff
    }

    @Override    
    public void updateStatus(int orderId, String status) {
        Order order = orderRepository.findById(id);
        
        // but how about this?? this still requires me to use if/else or switch
    }
}

As you can see, I can do it while creating the Order in the store(Order order) method, but I have no idea to do it in updateStatus(int orderId, String status) since it is still required to check status value to use the right state.

switch (status) {
    case "EXPIRED": {
        ExpiredState state = ExpiredState.getInstance();
        OrderContext context = new OrderContext(state, order);
        context.updateState();

        // do something
        break;
    }
    case "CANCELED": {
        CanceledState state = CanceledState.getInstance();
        OrderContext context = new OrderContext(state, order);
        context.updateState();

        // do something
        break;
    }
    // other case
    default:
        // do something
        break;
}

The exact reason to implement the state design pattern is to minimize "the switch stuff/hardcoded checking" and the flexibility for adding more state without breaking current code (Open/Close principle), but maybe I'm wrong, maybe I'm lack of knowledge, maybe I'm too naive to decide to use this pattern. But at the end of the day, I found out that I still need to use the switch stuff to use the state pattern.

Then, what's the right way to handle the order status changes?

Answer 1

The exact reason to implement the state design pattern is to minimize "the switch stuff/hardcoded checking" and the flexibility for adding more state without breaking current code (Open/Close principle)

Polymorphism does not replace all conditional logic.

but maybe I'm wrong, maybe I'm lack of knowledge, maybe I'm too naive to decide to use this pattern.

Consider what behaviors actually change in response to an order's status change. If no behaviors change, there's no reason to use the State pattern.

For example, if the order's behavior does not change, assigning an integer (or enum) or string as an order status is fine:

enum OrderStatus {
    WAITING,
    CANCELLED,
    EXPIRED,
    PURCHASED
}

class Order {
    private OrderStatus status;
    
    public Order() {
        status = OrderStatus.WAITING;
    }
    
    public void setStatus(OrderStatus s) {
        status = s;
    }
    
    public void doOperation1() {
        System.out.println("order status does not affect this method's behavior");
    }
    
    public void doOperation2() {
        System.out.println("order status does not affect this method's behavior");
    }

    public void doOperation3() {
        System.out.println("order status does not affect this method's behavior");
    }
}

If doOperation()s remain the same despite status changes, this code works fine.

However, real problems start to occur when doOperation()s' behaviors change due to status changes. What you'll end up with is methods that look like this:

...
    public void doOperation3() {
        switch (status) {
        case OrderStatus.WAITING:
            // waiting behavior
            break;
        case OrderStatus.CANCELLED:
            // cancelled behavior
            break;
        case OrderStatus.PURCHASED:
            // etc
            break;
        }
    }
...

For many operations, this is unmaintainable. Adding more OrderStatus will become complex and affect many Order operations, violating the Open/Closed Principal.

The State pattern is meant to address this problem specifically. Once you identify which behaviors change, you extract them to an interface. Let's imagine doOperation1() changes:

interface OrderStatus {
  void doOperation1();
}

class WaitingOrderStatus implements OrderStatus {
  public void doOperation1() {
    System.out.println("waiting: doOperation1()");
  }

  public String toString() {
    return "WAITING";
  }
}

class CancelledOrderStatus implements OrderStatus {
  public void doOperation1() {
    System.out.println("cancelled: doOperation1()");
  }

  public String toString() {
    return "CANCELLED";
  }
}

class Order implements OrderStatus {
    private OrderStatus status;
    
    public Order() {
        status = new WaitingOrderStatus();
    }
    
    public void setStatus(OrderStatus s) {
        status = s;
    }
    
    public void doOperation1() {
      status.doOperation1();
    }
    
    public void doOperation2() {
        System.out.println("order status does not affect this method's behavior");
    }

    public void doOperation3() {
        System.out.println("order status does not affect this method's behavior");
    }
}

class Code {
    public static void main(String[ ] args) {
        Order o = new Order();
        
        o.doOperation1();
    }
}

Adding new states is easy and it adheres to the Open/Closed Principal.