3

Here are the main classes I can think off the top of my head. All business objects will follow the abstraction (implement interfaces). I have not mentioned interface names to avoid verbosity. I have mainly focused on high level scheduling algo and high level classes without going into too much details

Principles I mainly followed here are :-

  1. Single Responsibility Principle(every class is worried about own concern)
  2. Open for extension closed for modification(see strategies)
  3. Tell don't ask (Clubbed the behavior with state in elevator class behavior operates on its own state) Abstraction/Polymorphic

Domain Objects :-

Elevator - Here is the State

  1. floorButton(will contain the list of floor buttons in elevator)

  2. elevatorRequest it will contain the elevator requests in ascending order if direction is UP otherwise it will contain in descending order if direction is DOWN.

  3. currentDirection(UP or DOWN)
  4. currentFloor
  5. currentState(Running/Idle/Maintenance etc)

    Here is the behavior

  6. run(...) :- It will process the elevatorRequest till it is empty. if list is not empty, it will set its state to Running , set the directiion based on comparison of it currentFloor and any request in elevatorRequest and print running . Tt will also check the each elevator Request in list elevatorRequests in sequential order and check if it is equal to getcurrentFloor(). If yes print "Reached Floor" + currentFloor. Else make the state as Stopped
  7. setCurrentFloor() :- Whenever elevator reach to any floor , it will call this method to set the currentFloor.
  8. openDoor()
  9. closeDoor()
  10. reset()

Button -

  1. Floor Button (Button inside elevator to place elevator request)
  2. Direction Button(Button outside elevator to call elevator)

ElevatorRequest

  1. floorNumber
  2. direction
  3. time

Controller/Business Objects :-

ElevatorController - For handling http request and delegate it to ElevatorRequestManager

  1. processElevatorRequest(..)
  2. processFloorRequest(..)

ElevatorScheduleManager - To place the request we can use different kind of strategies like timebased, direction based etc. Here i will use DirectionBased Strategy. Here is the DirectionBasedStrategy

  1. processRequest(...) Pattern- It will follow factory pattern to create the one of the child object of strategy based on parameter(can be configured in property file)

DirectionBasedStrategy -

  1. It will check the currentState of elevator,
  2. If Elev is in Idle state, it will place the floorRequest in list named as ElevatorRequest. Else call ElevatorRequestManager to place the request in set(Tree based) pendingRequests
  3. If Elev is in Running state, it will get the currentDirection . If it matches with ElevatorRequest direction and current floor is less than ElevatorRequest floor it will place the request in floorRequest list. Else call ElevatorRequestManager to place the request in set pendingRequests I have chosen the TreeSet so that request can be stored in in order of time and does not contain duplicate entries
  4. processRequest(...)

ElevatorRequestManager- This will place the ElevatorRequest in some data structure like list. Here we wil two classes DownwardElevatorRequestManager and UpwardElevatorRequestManager

  1. processRequest(...)
  2. processPendingRequest(...) This method will start the thread that will keep on running. This will again use the DirectionBasedStrategy. This will poll the pendingRequests to pick the requests in the same direction until the last request in that direction. Once all the requests are picked , it will remove the requests from pendingRequests and put it in elevatorRequest and call run method on elevator. To pick the move direction , it will pick the direction from first request under pendingRequests(it already contains the request in time order)

Update :- My question is to review this design/principles at high level

closed as unclear what you're asking by Doc Brown, Tulains Córdova, TMN, gnat, Andres F. Nov 18 '16 at 21:18

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    What do you mean by "Clubbed the behavior with state in elevator class behavior operates on its own state" ? Also, what is the question being asked? – Tulains Córdova Nov 18 '16 at 13:52
  • 2
    Possibly relevant: Open letter to students with homework questions – Dan Pichelman Nov 18 '16 at 14:06
  • 4
    If you don't have a question to ask, don't expect someone to answer. – Doc Brown Nov 18 '16 at 15:06
  • this guidance from site moderator looks appropriate: Are Design Review questions on-topic? – gnat Nov 18 '16 at 17:52
  • 1
    @TulainsCórdova Tell Don't Ask principle(TDA) says ` Behavior (which is dependent only on its object state) should be kept inside the object itself` – M Sach Nov 19 '16 at 11:12