views:

3527

answers:

2

There are a set of questions that seem to be commonly-used in interviews and classes when it comes to object-oriented design and analysis. This is one of them; unfortunately, my OOP professor in college never actually gave an answer to it, and so I've been wondering.

The problem is as follows: design a basic set of objects/methods to be used to simulate an elevator bank. What are the objects and their attributes/methods?

For the sake of argument, let us assume that our building has twenty floors; the bottom floor is the lobby, and the second floor connects to the parking garage (therefore, people will enter/exit the building on either the bottom floor or the second floor). There is one elevator bank that services all the floors; there are three elevator shafts in the elevator bank, and one elevator per shaft.

What would be the correct way to model this in an object-oriented model?

+3  A: 

I've seen many variants of this problem. One of the main differences (that determines the difficulty) is whether there is some centralized attempt to have a "smart and efficient system" that would have load balancing (e.g., send more idle elevators to lobby in morning). If that is the case, the design will include a whole subsystem with really fun design.

A full design is obviously too much to present here and there are many altenatives. The breadth is also not clear. In an interview, they'll try to figure out how you would think. However, these are some of the things you would need:

1) Representation of the central controller (assuming there is one).

2) Representations of elevators

3) Representations of the interface units of the elevator (these may be different from elevator to elevator). Obviously also call buttons on every floor, etc.

4) Representations of the arrows or indicators on each floor (almost a "view" of the elevator model).

5) Representation of a human and cargo (may be important for factoring in maximal loads)

6) Representation of the building (in some cases, as certain floors may be blocked at times, etc.)

Uri
+4  A: 

First there is an elevator class. It has a direction (up, down, stand, maintenance), a current floor and a list of floor requests sorted in the direction. It receives request from this elevator.

Then there is a bank. It contains the elevators and receives the requests from the floors. These are scheduled to all active elevators (not in maintenance).

The scheduling will be like:

  • if available pick a standing elevator for this floor.
  • else pick an elevator moving to this floor.
  • else pick a standing elevator on an other floor.
  • else pick the elevator with the lowest load.

Each elevator has a set of states.

  • Maintenance: the elevator does not react to external signals (only to its own signals).
  • Stand: the elevator is fixed on a floor. If it receives a call. And the elevator is on that floor, the doors open. If it is on another floor, it moves in that direction.
  • Up: the elevator moves up. Each time it reaches a floor, it checks if it needs to stop. If so it stops and opens the doors. It waits for a certain amount of time and closes the door (unless someting is moving through them. Then it removes the floor from the request list and checks if there is another request. If so the elevator starts moving again. If not it enters the state stand.
  • Down: like up but in reverse direction.

There are additional signals:

  • alarm. The elevator stops. And if it is on a floor, the doors open, the request list is cleared.
  • door open. Opens the doors if an elevator is on a floor and not moving.
  • door closes. Closed the door if they are open.
Gamecat