Design Order Tracker

medium

Design the OrderStatus model used by an OrderTracker class. An order begins as PLACED and moves through a controlled workflow. Some statuses have more than one possible next step, while completed or cancelled orders cannot move at all.

The valid transitions are:

PLACED -> PACKED or PLACED -> CANCELLED
PACKED -> SHIPPED or PACKED -> CANCELLED
SHIPPED -> DELIVERED
DELIVERED and CANCELLED have no outgoing transitions

The OrderTracker class is provided. Complete the missing OrderStatus enum—or the closest enum-like type in your language—so the tracker behaves as follows:

OrderTracker() creates an order in the PLACED status with a step count of 0.
String status() returns the current status name.
boolean advanceTo(String target) moves to target and returns true only when the name is recognized and the transition is allowed from the current status. Otherwise, it returns false without changing the status or step count. Status names are case-sensitive.
String[] allowedNext() returns the statuses directly reachable from the current one, preserving the order shown above.
boolean isTerminal() returns true when the current status has no valid next status.
int stepCount() returns the number of successful transitions. Rejected attempts do not count.

Keep the transition rules with the status model rather than duplicating them inside the tracker. Adding another status later may extend OrderStatus, but it should not require rewriting advanceTo, allowedNext, or isTerminal.

Read the supplied tracker carefully to see the exact members and methods expected from OrderStatus in your language.

Example 1:

Input:

Output:

Explanation: A new order is PLACED, from which it can be packed or cancelled. Moving to PACKED is allowed and counts as one step.

Example 2:

Input:

Output:

Explanation: An order cannot jump straight from PLACED to SHIPPED, so the move is refused and the status is unchanged. Cancelling from PLACED is allowed, and a cancelled order can go nowhere else.

Constraints:

target consists of uppercase English letters.
At most 100 calls will be made across all methods.

How the design is graded

needs 7/10 to pass

Enum modelling
Full marks when the five statuses are a closed set of values (an enum, or the closest equivalent the language offers) and the moves allowed out of each status are declared once alongside that set. Lose points for loose status strings compared throughout, or for the transition table being spelled out inside the tracker.
Rules derived from one table
Full marks when advanceTo, allowedNext and isTerminal all read the same declaration of allowed moves, so a terminal status is simply one with nowhere to go. Lose points when terminal statuses are listed separately from the transition table, or when the allowed moves are written out more than once.
Structure and naming
Full marks when a refused move leaves the status and the step count untouched, an unrecognised status name is handled deliberately, and names are descriptive with no dead code. Lose points when a rejected move still counts as a step, or 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.

Hints

Call	Returns
new OrderTracker()	null
status()	"PLACED"
allowedNext()	["PACKED","CANCELLED"]
advanceTo("PACKED")	true
status()	"PACKED"
stepCount()	1