Design Traffic LighteasyDesign Traffic Light
Picture a traffic light at a quiet intersection. It always follows the same rhythm—red, green, yellow, then back to red—but each color carries its own instruction for drivers. Instead of teaching the light a list of color checks, we will let each color describe itself and choose what comes next.
The TrafficLight context is already implemented for you. A new light starts in red, delegates color-specific work to its current state, and keeps track of how many times it has changed.
Your task is to implement the State pattern pieces:
- the
TrafficLightStatecontract; RedState,GreenState, andYellowState.
Every state reports its color, returns its driver-facing message, and creates the state that follows it. The provided context uses those three answers to run the cycle.
Each color has its own message:
- red returns
"RED light - Stop" - green returns
"GREEN light - Go" - yellow returns
"YELLOW light - Slow down"
The cycle runs red, then green, then yellow, then red again, and repeats without limit. change() returns the message for the color being left—not the color that becomes active afterward.
Do not rewrite TrafficLight. Complete only the marked state interface and state classes. The tests call the provided context and verify the messages, cycle, read-only queries, and change count.
Example 1:
Input:
Output:
Explanation: A new light shows red, so the first change returns the red message and moves the light to green. The second returns the green message and moves it to yellow, which leaves the count at 2.
Example 2:
Input:
Output:
Explanation: Six changes run two full laps. Yellow hands back to red on the third and the sixth call, and the light finishes showing red.
Constraints
- At most
100calls in total are made across all methods.
How the design is graded
needs 7/10 to pass- State separation
Full marks when each color is its own class behind one contract, and `change` asks the current state for its message and its successor without naming a color anywhere. Lose points heavily when `TrafficLight` branches on a color name or an index, or when the three message strings appear inside `TrafficLight`.
- Transitions belong to the states
Full marks when each state names the state that follows it, so the whole cycle is three one-line answers and closes because yellow points back at red. Lose points when the context works out the next color, or when the wrap-around is arithmetic on a counter the context maintains.
- Structure and naming
Full marks when `change` returns the message for the state it is leaving and counts one change, `currentColor` and `currentMessage` advance nothing, and the counter lives on the light rather than inside a color. 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 TrafficLight() | null |
| currentColor() | "RED" |
| change() | "RED light - Stop" |
| currentColor() | "GREEN" |
| change() | "GREEN light - Go" |
| currentColor() | "YELLOW" |
| changeCount() | 2 |
A new light shows red, so the first `change` returns the red message and moves the light to green. The second returns the green message and moves it to yellow, which leaves the count at 2.
Run checks these cases. Submit also runs a larger hidden set.