Win a copy of Serverless Applications with Node.js this week in the NodeJS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Stephan van Hulst
  • Ron McLeod
  • Tim Moores
  • salvin francis
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Vijitha Kumara

Design an Elevator System  RSS feed

 
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My friend was asked to design an elevator system for a building with 50 floors and 4 elevators in a recent interview. This seems like a very open-ended question and I wanted to try my hand at it. I have come up with a few classes that I think will suit the use cases and is also extensible.
I would clarify this with an interviewer in a real interview, but I have made the following assumptions:

  • The elevators are all capable of serving all 50 floors. They are not divided into serving a specific set of floors.
  • There are no special or express elevators.
  • There will be peak and off-peak usage patterns.
  • The button panel on floors will be able to take the actual destination floor as input rather than just the direction. There is no special reason for this assumption, just that this was how it was in the last high-rise hotel I was staying at.
  • The elevators themselves have no buttons apart from close door, alarm, open door(I have not accounted for these in my classes since I felt they are not central to the design).


  • Please point out the bad/negative aspects of the design/assumptions and my overall idea. Please let me know putting yourself in the shoes of an interview the aspects you liked.

    P.S. I am a C# developer by trade, so the declarations and casing adhere to standard C# conventions. I apologize for any convenience due to this. But given the syntactical similarity between the languages, the code is hopefully clear enough from a readability standpoint.

     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sorry, I am not sure why my classes show up in a small white box in my original post. Add this post to make it more readable.

     
    Saloon Keeper
    Posts: 9997
    208
    • Likes 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Why did you include all kinds of aspects in your API that didn't appear in your problem description? If the problem is mostly about scheduling, then why should I be interested in capacity and weight? If those are important in how the elevators are scheduled, then why didn't they appear in your initial problem description? Why do I care that a button should illuminate?

    Your API is rife with implementation details. If an Elevator has a GetCurrentFloor() accessor, then why are you including a currentFloor field? Why are you giving an implementation for the OnRequestReceived event handler?

    C# has properties. Why aren't you using them? Why aren't there event declarations in your API? Most importantly, why aren't there constructors, so I can see what dependencies a class relies on?

    You're using inappropriate types. A long is a poor representation for an instant of time. Why do you have int to represent floors in some cases and char to represent them in other cases? Be consistent.

    If you're using a Queue for stops, how are you going to insert a stop when it turns out that inserting a stop is more efficient than adding the stop at the end of the queue?

    How is a scheduling strategy going to be effective when the only information it has is the request? Why doesn't a strategy have access to the available elevators or their current schedules?

    What does it mean to "Set a request" in your ElevatorController?
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for the detailed feedback. I apologize for the ambiguity and the inconsistency in my code. My immediate goal is to figure out if I have the right set of classes for the given specifications and then move on to the scheduling solution. That being said, I also intend to do a fully implemented solution eventually - hence the additional implementation detail skeleton code.

    The capacity is central to both the scheduling strategies. My idea of the EnergyEfficientStrategy is:

  • Check if an elevator is within 3 floors and already moving in the direction of the request.
  • If yes, choose this elevator for the request even if there is an idle elevator closer.
  • If the capacity exceeds the limit by the time it gets to the request floor, return the request to the controller to be assigned to another elevator.


  • My idea of the ShortestWaitTimeStrategy is:

  • Check the closest elevator from the request floor(idle or moving).
  • If there is a tie between two idle elevators choose the one with the lower total weight.


  • C# has properties. Why aren't you using them? Why aren't there event declarations in your API? Most importantly, why aren't there constructors, so I can see what dependencies a class relies on?


    Fixed this.

    You're using inappropriate types. A long is a poor representation for an instant of time. Why do you have int to represent floors in some cases and char to represent them in other cases? Be consistent.


    And this.

    If you're using a Queue for stops, how are you going to insert a stop when it turns out that inserting a stop is more efficient than adding the stop at the end of the queue?


    Added a comment and changed the type to a PriorityQueue. Will this work?

    How is a scheduling strategy going to be effective when the only information it has is the request? Why doesn't a strategy have access to the available elevators or their current schedules?


    The idea is to query the controller for the available elevators, employ some custom comparison mechanism that determines the best elevator and chooses it from the list.

    What does it mean to "Set a request" in your ElevatorController?


    Added a comment to clarify this.

     
    Sheriff
    Posts: 24295
    55
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Saikrishnan Srivatsan wrote:

    If you're using a Queue for stops, how are you going to insert a stop when it turns out that inserting a stop is more efficient than adding the stop at the end of the queue?


    Added a comment and changed the type to a PriorityQueue. Will this work?



    I am doubtful about that. If you're going to have strategies which control how the elevators work, wouldn't the PriorityQueue have to know about what strategy the elevator is using?

    Or is it that the strategy is used to decide whether or not to add a floor to an elevator's queue?
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    The SchedulingStrategy is only to determine which of the four elevators the current request goes to. The PriorityQueue<int> of activeStops within each elevator is only for that elevator. The top will always have the next floor it needs to make a stop at. I cam unable to think of a more efficient way to insert stops to the list of stops an elevator has.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Or is it that the strategy is used to decide whether or not to add a floor to an elevator's queue?


    Yes. Strategy determines which elevator the request goes to. PriorityQueue in the elevator will have its own comparer to sort the stops and the top(min/max) will be the next stop it stops at.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 9997
    208
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Your ISchedulingStrategy interface is deficient. There's no way for any strategy to be implemented without intimate knowledge of the core business model, and the power to modify the application state. This is very dangerous. Strategies should strive to be stateless, and all relevant information should be passed in the method parameters. Instead of modifying the business model, a strategy should return a decision, and the business model should use the decision to modify itself.

    I would use a strong type to represent a floor. It will make your code much nicer to read, and you can also use it to represent levels that aren't associated with a number. Just this morning I stepped in an elevator that had the levels -1, E, L, 1, 2, 3, ...

    I think the RequestDirection enum is useless. Instead of telling an elevator to move in a specified direction, just let it move closer to the next scheduled stop.

    Why does ElevatorRequest have private setters? If the properties are intended to be read-only, remove the setters completely. Same goes for all your other classes.

    The RequestTime parameter of the ElevatorRequest doesn't follow naming conventions. Start it with a lower-case letter.

    What is the purpose of a Button? It looks like a useless wrapper around a floor ID. And what is the purpose of a ButtonPanel? Why not just call the ElevatorRequest constructor directly?

    Why does an elevator need an ID?

    The name 'capacity' does not clearly indicate whether it concerns weight or volume.

    Property names should start with a capital letter.

    I wouldn't use a PriorityQueue to hold your scheduled stops, because you will never be able to schedule stops in the opposite direction until the queue is completely empty. A simple List will do. Besides, I don't think PriorityQueue is a standard class in the .NET API.

    Don't let a class react to events that it raises itself. Just call a method directly from the place where the event is raised.

    SetElevatorRequest is a really poor name. Name it something like RequestRide instead.

     
    Stephan van Hulst
    Saloon Keeper
    Posts: 9997
    208
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Here is a Floor class you could use:
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Here is a Floor class you could use:



    Thank you so much for this and for helping out overall.

    I would use a strong type to represent a floor. It will make your code much nicer to read, and you can also use it to represent levels that aren't associated with a number. Just this morning I stepped in an elevator that had the levels -1, E, L, 1, 2, 3, ...

    I think the RequestDirection enum is useless. Instead of telling an elevator to move in a specified direction, just let it move closer to the next scheduled stop.

    Why does ElevatorRequest have private setters? If the properties are intended to be read-only, remove the setters completely. Same goes for all your other classes.

    The RequestTime parameter of the ElevatorRequest doesn't follow naming conventions. Start it with a lower-case letter.

    What is the purpose of a Button? It looks like a useless wrapper around a floor ID. And what is the purpose of a ButtonPanel? Why not just call the ElevatorRequest constructor directly?

    Why does an elevator need an ID?

    The name 'capacity' does not clearly indicate whether it concerns weight or volume.

    Property names should start with a capital letter.

    I wouldn't use a PriorityQueue to hold your scheduled stops, because you will never be able to schedule stops in the opposite direction until the queue is completely empty. A simple List will do. Besides, I don't think PriorityQueue is a standard class in the .NET API.

    Don't let a class react to events that it raises itself. Just call a method directly from the place where the event is raised.

    SetElevatorRequest is a really poor name. Name it something like RequestRide instead.



    I promise I have made these changes, but before posting it here again, I would really like to get the logic behind the scheduling strategy right since that is the core of the problem and would really appreciate some pointers on how I could make it self-sufficient.



    I have added the list of elevators as a parameter(returning an elevator instead of void) and will be determining the state of each of them and choosing the most optimal one to serve the request at hand. Is this sufficient information for the strategy to work? If not, I would like to clarify if I am even thinking along the right lines as to what is required for it to be self-sufficient? Does it need the activeRequests of the controller itself as opposed to having just the requests currently served by each of the elevators? I am a little lost for ideas.

    My assumption is that the SchedulingStrategy is the one that determines the rules that govern which elevator the request should go to.
     
    Sheriff
    Posts: 13387
    221
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    seems very open-ended


    Sure does and it looks like you fell right into the open end. Set a time limit for yourself. Better yet, set a limit to the scope. As it is now, you're already doing a lot of speculative design. That's going to take forever and a day.

    State what behavior you want first, then come up with a reasonably limited API to support that behavior. Buttons illuminating and other stuff like that, well, that's all bells and whistles. Elevator controller, energy efficiency, scheduling strategy, ... wow, you're really going to town and yet I don't know if you have any basic working software yet. You can't design everything up front. More often than not, that never ends well nor does it get you close to where you should be.

    If I were to do this, I'd start with one class: Elevator.  Then figure out what it needs to do incrementally and iteratively.

    Say you had time and money to only implement one feature, what would that feature be? Probably that the elevator could be made to go to a specific floor. That means I'd (maybe) have an API like this:
    + goTo(int floor)

    That's it. If I got that to work, then I'd start thinking about what kind of scenarios would use this API:

    1. Go to a floor in response to a call button on a floor pressed.
    2. Go to a floor in response to a floor number button in the elevator pressed

    Then think of what other things related to this you'd need to do with an elevator. And so on and so forth. I would not go hog wild and start thinking about button illumination and schedules and request times, etc. Those are all details you can worry about later.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 9997
    208
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    For a first iteration, I would go with this design:
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 9997
    208
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    The strategy would be used by the controller like this:
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    For a first iteration, I would go with this design:



    Thanks, that looks great

    The strategy would be used by the controller like this:



    Could you please help me understand why we need the stopIndex and why it is returned by the strategy? Is this to determine which index in the current list of stops the next stop needs to be inserted?

    On a related note, I see that the type of the ScheduledStops is a readonly list, how could we insert stops in this case?

    Could you also please help me understand why we need the two Events and and their corresponding EventArgs?

     
    Junilu Lacar
    Sheriff
    Posts: 13387
    221
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Maybe it's just me but in an interview setting, say with a time limit of a couple of hours, I wouldn't be looking for that much as an evaluator. In fact, if you came to me with that much "design," I'd be scared. I'd have to ask myself what kind of complex monstrosities would everybody have to deal with if we hired someone who could come up with all that in just a couple of hours? But again, it's just me. To others, having all that might be impressive but for me, simple is better.
     
    Junilu Lacar
    Sheriff
    Posts: 13387
    221
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    As an evaluator, here's what I'd be looking for:

    1. Does the candidate start out simple?
    2. Does the candidate use an iterative and incremental process?
    3. Does the candidate define tests up front?
    4. Does the candidate explore usage scenarios?
    5. Does the candidate inquire about features and their relative values?
    6. Does the candidate think about the user or do they dive into implementation detail?

    I find that as a candidate, I'm more impressed by evaluators who want to learn about my thought process rather than the design that I can actually come up with. Yes, technical design decisions are important but what's really important to me is that you understand the process for arriving at those technical design decisions. Think about it, if you're applying for a job at a company whose business has nothing to do with elevators, do you think they really care what kind of design for an elevator system you come up with? No! And if they do, then I probably don't want to join that company anyway. Unless, of course, that company actually does make elevators and/or elevator control systems.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Maybe it's just me but in an interview setting, say with a time limit of a couple of hours, I wouldn't be looking for that much as an evaluator. In fact, if you came to me with that much "design," I'd be scared. I'd have to ask myself what kind of complex monstrosities would everybody have to deal with if we hired someone who could come up with all that in just a couple of hours? But again, it's just me. To others, having all that might be impressive but for me, simple is better.



    I totally hear you Junilu, and I agree with you that it is way more than what you can typically come up with for a real world project in 2 hours. But the recent trend in some of the interviews I've had is to gauge how wide and deep the candidate could go - a lot of people do feel that that isn't the right way to go about it, but I was actually rejected recently for picking up one part of a big problem similar to this and starting simple. It was a 40 min interview and the feedback I was given was I did not go into the wider aspects of the problem. And like I had mentioned earlier, my aim is to be very good at this stuff and learn it the right way, but unfortunately the interviewing style of some companies now does not necessarily align with that line of thinking. So for short term gains, I'm having to go down this path. But I promise, when I actually sit down to do this for my pleasure/understanding/learning I will adopt the approach that you have mentioned.
     
    Junilu Lacar
    Sheriff
    Posts: 13387
    221
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Even before all that, I would ask:

    Does the candidate seek to understand the scope of the problem first?
    What kind of assumptions does the candidate make?
    Do they try to validate those assumptions?
    Do they try to list what those assumptions are?
    Do they understand where the boundary between software and hardware is?

    On that last question, I'd expect the candidate to be inquisitive about what responsibilities the software system should have over the hardware. This will help define the scope of the software and its features. If you come to me with a software design that include things like button illumination, I would not be impressed. As an engineer, I would be inclined to think that's more of a hardware-based concern.

    As an evaluator, it would be imperative for me that the candidate knows how to define bounds around the software system they're trying to build, otherwise, that designer could potentially cost my company a lot of money from over-engineering.
     
    Junilu Lacar
    Sheriff
    Posts: 13387
    221
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Saikrishnan Srivatsan wrote:It was a 40 min interview and the feedback I was given was I did not go into the wider aspects of the problem.


    Did you ask what they meant about "wider aspects"? It could have been that they just meant what I mentioned earlier, that they were looking for you to explore the boundaries of the problem to define where software ended and hardware began. Maybe they were looking for you to ask the kind of questions I was referring to. To me, those are the "wider aspects" of the problem.
     
    Saikrishnan Srivatsan
    Ranch Hand
    Posts: 67
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:The strategy would be used by the controller like this:



    Could you please clarify who is likely to be the consumer of the events "StopScheduledEventHandler" and "ArrivalEventHandler"? Let us say that the strategy schedules a stop and raises this event. Why would we need the elevator to react to this(assuming this is why we have the delegate?) the stop has already been scheduled, isn't it?
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 9997
    208
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You mean the StopScheduled and the ArrivedAtFloor events. The StopScheduledEventHandler and ArrivalEventHandler delegates are the handler types of these events.

    An example of a consumer of these events would be a user interface that displays where elevators currently are and where they will be making a stop.
     
    Junilu Lacar
    Sheriff
    Posts: 13387
    221
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I have never seen nor even heard of elevator systems with the floor buttons outside the elevators but apparently they allow for more efficient transport of people. See this article from Forbes: https://www.google.com/amp/s/www.forbes.com/sites/quora/2012/06/15/why-dont-elevators-allow-you-to-toggle-whether-they-stop-at-a-floor/amp/

    Interesting...
     
    Junilu Lacar
    Sheriff
    Posts: 13387
    221
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I also learned that the elevator close door button often doesn't actually work under normal operating conditions. It's just there as a placebo.
     
    Space pants. Tiny ad:
    global solutions you can do at home or in your backyard
    https://www.kickstarter.com/projects/paulwheaton/better-world-boo
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!