State pattern - Elevator LLD implementation Observation

[kopalag]

Hi,

Thanks for sharing this Elevator LLD implementation—it’s a great reference overall.

I had a design-related observation regarding the State Pattern used in the elevator solution.

Observation:

In the current design, the ElevatorState interface defines:

move()

addRequest()

From a State Pattern perspective, the State interface should ideally expose only those actions that can cause a state transition. However, addRequest() does not directly influence the elevator’s state—it only mutates internal data (request queue), not the state itself.

Including addRequest() in ElevatorState slightly violates the intent of the pattern, as it mixes state-independent behavior with state-transition behavior.

Recommended Design Change

I would suggest:

Removing addRequest() from ElevatorState

Keeping request handling in the Elevator (context) or a dedicated scheduler

Defining direction-specific state-changing actions in the ElevatorState interface:

interface ElevatorState {
    void moveUp();
    void moveDown();
}

Proposed States
IdleState

MoveUpState

MoveDownState

Each concrete state would:

Decide whether moveUp() / moveDown() is valid

Handle its own state transitions internally

Reject or ignore invalid actions (e.g., moveUp() in MoveUpState)

Why This Better Fits the State Pattern?

Clear separation between state transitions and business logic

State classes encapsulate only state-specific behavior

Reduced responsibility leakage into the context

Easier extensibility for future states (e.g., MaintenanceState, EmergencyState)

I understand this may have been an intentional simplification, but I wanted to raise this as a design discussion since the current approach feels closer to a controller-driven design than a strict State Pattern implementation.

Looking forward to your thoughts. Thanks again for the open-source contribution!