An online order does not react to every request in the same way. Paying makes sense when the order has just been placed, shipping is allowed only after payment, and cancellation is no longer possible once the parcel is on its way. We want each stage of the order to own those decisions instead of collecting them in one large conditional.
The Order context is already implemented for you. It stores the order id and current state, delegates every action to that state, and exposes setState(...) for transitions. Your task is to implement the State pattern pieces:
OrderState contract;PlacedState, PaidState, ShippedState, DeliveredState, and CancelledState.Every state must implement pay, ship, deliver, cancel, and name. An action either returns the required message and moves the context to a new state, or returns a refusal message without changing anything.
While the order is placed:
pay() returns "Order <id> paid." and moves the order to paid.ship() returns "Cannot ship. Order not paid yet."deliver() returns "Cannot deliver. Order not shipped yet."cancel() returns "Order <id> cancelled." and moves the order to cancelled.While the order is paid:
pay() returns "Order already paid."ship() returns "Order <id> shipped." and moves the order to shipped.deliver() returns "Cannot deliver. Order not shipped yet."cancel() returns "Order <id> cancelled. Refund issued." and moves the order to cancelled.While the order is shipped:
pay() returns "Order already paid."ship() returns "Order already shipped."deliver() returns "Order <id> delivered." and moves the order to delivered.cancel() returns "Cannot cancel. Order already shipped."Once the order is delivered, all four operations return "Order already delivered." Once it is cancelled, all four return "Order is cancelled."
Cancellation is allowed while the order is placed or paid, and refused from the moment it ships. <id> stands for the id available through context.getOrderId() (or the equivalent method in your language).
Do not rewrite Order. Complete only the marked state interface and state classes. The tests interact with the provided Order class and will verify both returned messages and state transitions.
Input:
Output:
Explanation: The order runs the full sequence and reaches DELIVERED. Cancelling after delivery is refused, and the state stays where it was.
Input:
Output:
Explanation: Cancelling straight from placed reports no refund, because nothing has been paid. Every operation after that gets the cancelled answer.
1 <= orderId.length <= 20100 calls in total are made across all methods.Full marks when each of the five states is its own class implementing all four operations behind one contract, and `Order` forwards each call without asking which state it holds. Lose points heavily when `Order` branches on a state name, or when it tracks progress with `paid` and `shipped` booleans instead of a state object.
Full marks when a refused operation returns its message and performs no transition, so shipping an unpaid order, paying a paid order and cancelling a shipped order all leave `currentState` exactly as it was. Lose points when a refusal transitions anyway, or when the refusal messages are produced by a check inside `Order` before it delegates.
Full marks when the two terminal states answer with their own distinct messages, cancelling a paid order reports the refund while cancelling a placed order does not, and the order id is read from the context rather than copied into every state. Lose points for printing to stdout.
Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.
| Call | Returns |
|---|---|
| new Order("ORD-001") | null |
| pay() | "Order ORD-001 paid." |
| ship() | "Order ORD-001 shipped." |
| deliver() | "Order ORD-001 delivered." |
| cancel() | "Order already delivered." |
| currentState() | "DELIVERED" |
The order runs the full sequence and reaches `DELIVERED`. Cancelling after delivery is refused, and the state stays where it was.
Run checks these cases. Submit also runs a larger hidden set.

