TLDR: An elevator system must manage multiple cars, floors, and concurrent requests using a Dispatch Algorithm to minimize wait time. We use the State Pattern for elevator movement and the Strategy Pattern for dispatching, with the SCAN sweep algorithm at the core.

---

📖 The Hotel Lift Problem: What We Are Designing

A hotel has 10 floors and 3 elevators. At any moment:

• External requests come in: "Someone on Floor 5 pressed UP."
• Internal requests come in: "Someone inside Lift 1 pressed Floor 10."
• The system must decide which car to dispatch, and which order to serve floors.

This is a classic State Machine + Scheduling design. The key insight is that a lift behaves differently based on its current state — and we should model that explicitly.

---

🔢 Domain Model: The Core Entities

classDiagram
    class Building {
        +List~ParkingFloor~ floors
        +List~ElevatorCar~ cars
        +Dispatcher dispatcher
    }
    class ElevatorCar {
        +int id
        +int currentFloor
        +Direction direction
        +ElevatorState state
        +TreeSet~Integer~ stops
        +handleRequest(Request r)
        +move()
    }
    class Dispatcher {
        +ElevatorCar assign(Request r)
    }
    class Request {
        +int sourceFloor
        +Direction direction
    }

    Building --> ElevatorCar
    Building --> Dispatcher
    Dispatcher --> ElevatorCar

• ElevatorCar: Holds a sorted set of destination floors. Has a state (IDLE, MOVING_UP, MOVING_DOWN).
• Dispatcher: The brain. Assigns incoming Request to the best car.
• Request: Either ExternalRequest (floor + direction pressed outside) or InternalRequest (destination floor pressed inside the car).

---

⚙️ The SCAN Algorithm: Why Not First-Come-First-Served?

FCFS is naive: if requests come from floors 10, 1, 10, the lift zigzags 1→10→1→10 (4 × 9 = 36 floors traveled).

The SCAN Algorithm (also called Elevator Algorithm):

1. Move in the current direction (UP) serving all stops along the way.
2. When no more stops in that direction, reverse.

Toy example: Lift at Floor 4, moving UP. Requests: Floor 6 (UP), Floor 2 (DOWN), Floor 8 (UP).

Total travel: 6 floors instead of 18 (FCFS). This is why real elevators use SCAN variants.

---

🧠 State Pattern: Modeling Elevator Movement

An elevator's behavior depends on its current state. We make this explicit with the State pattern:

public interface ElevatorState {
    void handleRequest(ElevatorCar car, int targetFloor);
    String name();
}

public class IdleState implements ElevatorState {
    public void handleRequest(ElevatorCar car, int targetFloor) {
        car.addStop(targetFloor);
        if (targetFloor > car.getCurrentFloor()) {
            car.setState(new MovingUpState());
        } else if (targetFloor < car.getCurrentFloor()) {
            car.setState(new MovingDownState());
        }
    }
    public String name() { return "IDLE"; }
}

public class MovingUpState implements ElevatorState {
    public void handleRequest(ElevatorCar car, int targetFloor) {
        // SCAN: only add if it's above current floor
        if (targetFloor >= car.getCurrentFloor()) {
            car.addStop(targetFloor);   // serve on the way
        } else {
            car.deferRequest(targetFloor);  // serve on the next sweep
        }
    }
    public String name() { return "MOVING_UP"; }
}

The state transitions:

stateDiagram-v2
    [*] --> IDLE
    IDLE --> MOVING_UP : request above current floor
    IDLE --> MOVING_DOWN : request below current floor
    MOVING_UP --> IDLE : no more up requests
    MOVING_UP --> MOVING_DOWN : switch at top
    MOVING_DOWN --> IDLE : no more down requests
    MOVING_DOWN --> MOVING_UP : switch at bottom

---

⚙️ Dispatcher: Strategy Pattern for Assignment Policy

The Dispatcher uses the Strategy pattern so we can swap assignment algorithms:

public interface DispatchStrategy {
    ElevatorCar select(List<ElevatorCar> cars, Request request);
}

// Nearest-Car strategy: pick the car that will reach the requester soonest
public class NearestCarStrategy implements DispatchStrategy {
    public ElevatorCar select(List<ElevatorCar> cars, Request request) {
        return cars.stream()
            .filter(c -> c.canService(request))
            .min(Comparator.comparingInt(c ->
                Math.abs(c.getCurrentFloor() - request.getSourceFloor())))
            .orElse(null);
    }
}

canService() checks the car's state:

• IDLE → always serviceable.
• MOVING_UP → serviceable if request is above current floor and direction matches.
• MOVING_DOWN → serviceable if request is below current floor and direction matches.

---

⚖️ Design Patterns Applied

---

📌 Summary

• State Pattern models elevator direction changes as first-class state transitions — no branching spaghetti.
• SCAN Algorithm minimizes travel distance by sweeping in one direction before reversing.
• Strategy Pattern in the Dispatcher keeps assignment policy pluggable.
• Concurrent requests from multiple floors are handled via per-car TreeSet<Integer> of stops, which is auto-sorted.

---

📝 Practice Quiz

1. Why is FCFS (First Come First Served) a poor dispatch strategy for elevators?

   • A) It requires more memory.
   • B) It causes zigzag travel that maximizes floors traveled; SCAN sweeps in one direction, minimizing waste.
   • C) FCFS can't handle requests from multiple floors.
     Answer: B

2. In the State Pattern for elevator movement, what happens when a request arrives for a floor below the current floor while the car is MOVING_UP?

   • A) The car immediately reverses to MOVING_DOWN.
   • B) The request is deferred to the next downward sweep — the car continues upward first.
   • C) The request is rejected.
     Answer: B

3. What is the advantage of using a TreeSet<Integer> to store pending stops in an ElevatorCar?

   • A) It prevents duplicates and keeps stops automatically sorted by floor number, enabling in-order serving.
   • B) It uses less memory than a list.
   • C) It allows thread-safe concurrent modification without locks.
     Answer: A

---