withaspirit
commented
2 years ago It's a fun idea, but IDK if it's feasible given time constraints at this point.
Open withaspirit opened 2 years ago
withaspirit
commented
2 years ago It's a fun idea, but IDK if it's feasible given time constraints at this point.
This is a discussion for the possibility of moving RequestQueue to Scheduler. Basically, it would reduce the intelligence of the Elevator class and increase the responsibilities of the Scheduler. However, it would require more communication between Elevator and Scheduler.
The Elevator Monitor wouldn't need to have as much information. Scheduler could have something like a HashMap<Integer, ElevatorMonitor && RequestQueue> where ElevatorMonitor would be reduced to:
Pros:
One of the biggest benefits is that we could solely rely on Scheduler for updating the Elevator values displayed in the GUI.
Regarding the reduced intelligence of the Elevator class: Elevator wouldn't have to keep track of its own serviceDirection because that would be the concern of Scheduler. Elevator also would simply simply have a targetFloor and rely on receiving the latest targetFloor from Scheduler.
The Scheduler selection algorithm could add / remove requests to the requestQueues and estimate the queueTimes directly. This could also simplify the problem of #159. Currently, where the selection algorithm has to wait for Elevator to send out an ElevatorMonitor each time after it has received a ServiceRequest.
The chooseElevator method could also access the Elevator.hasNoRequests method directly.
Elevator also probably wouldn't have to worry about Elevator receiving a request after it's already started moving. IDK if that's been solved in another branch though.
Tradeoffs include not being able to test Elevator's movement with the RequestQueue without Scheduler passing it information. We might be able to compensate by moving the queue of SystemEvents from IntermediateHost to Scheduler and giving Scheduler an addEvent method.