Let me know whether you find the video useful. Also please don't forget to like the video and subscribe to this channel. Thanks :) Distributed System Design Interviews Bible | Best online resource for System Design Interview Preparation is now online. Please visit: www.thinksoftwarelearning.com? Please follow me on facebook.com/Think.Software.Community if you like to get notified about new course chapters getting added or any other updates. I will also take your suggestions there about the course and the channel.
I haven't finished the video, because I want to try it myself first. I had an idea for the following case. Elevator is @ floor 5, Before the doors close, floor 10 is requested, as the elevator begins to move floors 7,6 and 9 are requested. Would it be a good idea to scan the queue and put all requested floors into a min heap to handle requests between the interval [currentFloor - > requestedFloor]?
i have worked 27y in the elevator industry from field engineer to R&D hardware developer, software architect , project manager , R&D manager in two EU MNC.....it would be impossible to make an (OO) design of a an elevator controller in 45 minutes and describe all its nuances....and if that 45 minutes are the potential answer to an interview question at Google , it is very very messy.....i am preparing an elevator (mechatronic) design online course on my own but it is a HUGE topic...you have not cover even 0.01% of all potential elevator features/requirements (some of which even varies by region/country/city)
Thanks for the comment. The goal of this video also was not to design completely in 45 min and done with it. But just to provide food for thought and some hints about what are different things to consider 🙂. In interview also, the interviewer is not looking at you to solve the problem end to end but looking at how you tackle the question.
Your videos are really helpful. I have a suggestion if you could go on low level design like creating iterfaces/abstract classes for different actor and how will you club then in the elevator system class. And how these component will interact with each other. That would be better.
Nice video but you could have focused more on OOD as well. Like Button -> (Elevator Button, Hall Button) -> Elevator Button (Event Button, Floor Button) -> Event Button (Alarm Button, Fan Button, Light Button, Door Button). Here floor Button will only deal with floor functionality. Same for Fan, Door, Light etc button also. In this way SRP is not violated. Button interface can Have method like action(SystemInterface): void . Here SystemInterface can be extended by two classes ElevatorSystem and AdminSystem. for action methods under EventButton class we can prefer passing action(ElevatorSystem e): void and for HallButton we do action(AdminSystem a): void, bcz it deals on system to decide which elevator to sent on passenger floor.
I think the reason that we used enum to represent the { idle, going up, going down} states is because the state space should be only limited to these 3, whereas in the parking lot example there could be many types of parking spots that can be added even after first version of design is done. In the parking lot example, we designed it to be flexible so that when other types of spots are needed, they don't violate the Open/Close principle, but in this one we want the elevator states to be closed and not modified later.
@@ThinkSoftware thanks for this Video. Just a question to understand something: is a car full loaded not a state? or "out of service"? even "door open" is different than idle. If the car is full then it should not takes new Hall call... In case of a car "out of service": the dispatcher should not give hall call and "reload" the previous call to other elevator... So, I would like to know, if those example are not States then how do you advice to introduice it in the program? Thanks
I watched many videos on elevator design, but your content and way of explaining is super awesome. No one will get rejected in an interview if he can explain like this. Very satisfied. Thankyou very much !!!!!
> big tech companies This question was asked in client interview which was the last round in wipro recruitment process. I wasn't prepared for that, in fact coming from a tier 4 pvt college i never came across such question. But I did my best, and that was great interview experience. Me and the interviewer both drilled down into elevators for over an hour.
Love ur videos. Tis is my reasoning for a person class / Car class. A class is collection of DATA + FUNCTIONALITIES. Here a person has no direct functionality / data. hence no entity needed.
Thanks a lot for the video. Couple of questions 1. Do we need button class at all? Essentially we are creating InternalRequest and ExternalRequest when press ElevatorButton or HallButton respecitvely 2. For Button class , you drive ElevatorButton class and HallButton class from it. I think we should not have PressDown() in Button class as there is no equivalent in ElevatorButton . In real elevator buttons, there are only floor numbers buttons, help button, door open/close button etc but no up and down
I did not read all of the comments below, so maybe someone already mentioned this, but I believe a fourth elevator car state would be "out of service." Your videos are bringing together a lot of loose ends for me. Thank you.
I was expecting something like a UML's breakdown/discovery of classes, based on BEC architecture, Boundary, Entity, Controller objects per use-case. Like for example in your first use-case, 'calling elevator', what are the boundary objects, (buttons), entity objects (direction, destination), then a a controller object to carryout this use-case (which essentially responsible for the complexity of this 'calling elevator' use-case). I think your 'elevator system' object is interesting as well, its the dispatcher, may interact with per use-case controller objects, in this use-case to notify the progression of the elevator as it travels. Any thoughts on BEC driven oo design? Thanks.
This Rocks! Not the evelator, but the presentation! I've been wondering about this since college. Now I'm in a five floor building, it all makes sense. What if a vip is coming home to your house in a suprise visit.
I don't see how divide and conquer would help in this scenario. Most people would go from floor 1 to the floor where they live and back. Very rarely you would see people going to other floors from floor x != 1. You could have them change elevator cars midway or so, but that is quite an inconvenience (and it would be very annoying if I had to switch 3 or more cars to reach my floor from the bottom). Maybe an adaptive system based on real-time traffic would work, or maybe a division based on functional areas of the building: office floors, living floors, cafeteria/gym floors etc, but that would entail a lot of extra complexity.
let say when in an idle state, the dispatcher gets multiple requests, in either direction, first, the requests will be divided into going up or down. the dispatcher will first see max no. of requests, and add them into a min-heap and send the elevator closest to the top person who is there at the heap, and will not be idle until the heap is empty now or if the elevator reached either endpoint.
Thanks for the good content. One point here, no matter what others have covered on this topic, if you are creating a video on it, watchers get intrigued about how you would do it. A complete UML diagram at least would make it a self sufficient tutorial. Also I didn't get why you need ElevatorMotion interface. How does it fit in between 1. dispatcher and Elevator, 2. Internal button and elevator itself. That's why UML is important to know what is your design approach
Your info is really good. This information is very useful for those who have searched for this and you have great knowledge about this. I’m really impressed with this. Thank you so much.
I have seen practically, preallocate the elevators based on floor range and then apply the "Destination Dispatch Algorithm" based on the floor. This ensures Topmost going passenger need to wait due to some low-level floor passenger.
Hi Sir, thankyou for making such great content but there are only 2 videos for low level design . Please make more videos. In the paid course also , LLD videos are not there.
@@ThinkSoftware Bro why didn't you delve a lil deeper in the priority queue approach. Maybe that's the nature of how the interviews are conducted. Still a good job done
Before watching the video I was thinking something similar to LOOK ahead eventhough I never heard about it. I would try to do some combination of look but with timestamps along with booleans to decrease waiting time
enums are used to define limited and fixed number of varieties which are impossible to get modified in future as well. For e.g. Days of week, Months of year In case of parking lot there are possible changes of introducing new Spot type in future which have needed modification of existing classes and that goes against the Open close SOLID principle. In case of Elevator type, the direction is never going to change. It can only be up, down or idle even in future.
32:43, very interesting. So just to clarify, the hashmap is to handle request made from inside the elevator car, correct? Scan all floors from 0 - > N, when a button is pressed on a floor, mark the boolean as true The elevator will move up and then down, it will change its direction when it reaches the 0th and nth floor
Use 2 boolean arrays for the up and down direction, stopping at floors marked true, then marking the floor true, (request served )
Each elevator car also has a hasmap to keep track of the floors it should stop at, adding floors requested and then removing them when request is served.
The first part was good but the algorithm part was confusing. And at no in this video did you mention about state of the elevators controlled by the people who are inside the elevator. There would be a number pad inside the elevator where people press the actual floor button. For example, 10 people get in the elevator on floor 2. One of them wants to go to floor 1 and 9 of them want to go floor 100. Essentially it has two key functions: elevator summon and passanger dispatch. You haven't attempted to make any distinction between the two at any point in this video
@Thinksoftware please add some machine learning based system design questions such as ad prediction, search ranking etc. And how to approach these questions and how the requirements change for machine learning problems. Thank you
thank you for the video, why you didn't use (or talked) about the state design pattern when implementing the states on the elevator (up, down, idle states) , instead of using Enums ? is Enum more preferred ?
In this case, we know that we will only ever need 3 states (up, down, idle) and we will NEVER extend this functionality. So enum is sufficient, because we will never extend it.
Explained in a really simple way and to the Point. I would Like to know If Think Software Team has worked on Witness Horizon Software, as I am working on a Project to Simulate Different Call Strategies for a TWIN Elevator System. Thanks.
we need passenger class if we are having maximum load property for elevators.. Each person will have some particular weight that we need to take care of.
14:30 How will you accurately represent the specifications mentioned at 5:24, such as elevator car load, passenger throughput, passenger waiting time and passenger distribution, if there is no passenger actor involved in the model?
Why we are using ENUM? so the answer is UP,DOWN,IDLE these are the states of the Elevator and it can not be change, so we can say that its a constant property of elevator. In java if we want to define constant ENUM is the best choose.
This shows that you already know about elevator. Also there is no implementation. I would like to see requirement -> implementation. Refine requirement, refine implementation,
While we analyze use case, should we think from user's perspective ? like you said in video, the elevator can open doors and close doors, but I think it is not from user's perspective, that is what elevators can do, not users. I'd like to know more about it.
Functional requirement mentioned the need to check for the max weight and number of passengers translates to the max weight.. I did not get what we would not need the passenger class in this design as the above are calculated based on passenger object attributes
For the last use case for dispatcher algorithm where the elevator is going opposite direction to passenger, how is it different from the state where the elevator is going opposite direction to which the passenger wants to go? Seems like the same state else we are more inclined to say that passenger is on floor 1 and elevator is moving to any floor which is > 1, the last state did not make much sense to me or I got it wrong.. do let me know..
Thank you Think Software, this was really nice. I've just one question, in SCAN algorithm why we need priority queues when anyway we are using two boolean arrays for going up and down ? As, array indexes are already sorted and we have to look at each index of the array whether its set or not. What is the benefit we are getting by using priority queues?
The boolean array is used only for passengers who want to onboard the elevators. So if it is set for a floor then an elevator will stop at that floor and reset the value. Then the two priority queues or a single hashmap (for each elevator car) is used to store the destination floors that passengers riding the elevator car want to go. The same boolean array cannot be used for this purpose.
@@ThinkSoftware why cant the elevator also use a similar concept and maintain boolean array for destinations? everytime it waits at a floor to drop off pasengers it can be change the array to false and change it back to true when at least one passenger sets that floor as destination. would avoid heapify effort
ruclips.net/video/siqiJAJWUVg/видео.html For the lookahead in the LOOK algorithm, simply using a bitset is also a good option. 160 floors can fit into 20 bytes. We can test for each byte segment sequentially and from each byte one can access the digits with bit manipulation operations.
thanks for the comment. Such optimization are only need though if we are working on some embedded system with way less memory than the memory that is currently available in current computers.
Great as always. Is is possible make a video on 'how to identify actors', sometimes I get struck and ask "should this entity be an actor?", any help would be helpful.
I think even Doors would have hall and elevator implementations as when pressed hall button, the hall door should not open until elevator arrives whereas elevator door can open wherever its dispatched to. Am i right ?
Now a days elevator system moves horizontal also so we should have class and not enum for the elevator's states, just a suggestion :) But overall video is good. Please make a video on elevator's class diagram also
Could you please explain what the "Priority queues" are used for in the case of the SCAN algorithm? Because if I already have in the tru array where the elevator has to stop, I don't understand what's in the queues. Thanks
I was also wondering the same. May be priority queues (min heap for UP, max heap for DOWN) contain the destination floors which the persons inside the elevator might have pressed. Elevator checks these queues in order to drop the people.
I will disagree with the statement that we should not use Enums in cases where we may need to modify them, we never have 100% confidence that things will stay as they are. So instead we just need to use appropriate technics to encapsulate all the logic we are doing with specific Enums in one place or be sure that we will change it we will get error/warning from the not handled cases. In the case with a parking lot having classes is rather for the ability to add there some additional properties like size or specific structural differences.
You don't need passenger object for that. How will you even know the weight of each individual passenger? You will just keep track of total weight provided to the elevator by weight sensors
If one of the requirements is that we should be able to enforce such a limit than it can be done as you know the number of passengers boarding the elevator car at any time. Makes sense ?
First of all you need a mechanism to identify how many passengers on board or get off the elevator car. Secondly if needed, this can be done via a passenger counter in the elevator car. Why do you need a passenger class?
How do you know the weight of the passenger ? One could argue that if the elevator car refuses to move, the last person to get in should get out. I can think of other requirements but it is beyond scope. I agree we can get away without a class
Let me know whether you find the video useful. Also please don't forget to like the video and subscribe to this channel. Thanks :)
Distributed System Design Interviews Bible | Best online resource for System Design Interview Preparation is now online. Please visit: www.thinksoftwarelearning.com?
Please follow me on facebook.com/Think.Software.Community if you like to get notified about new course chapters getting added or any other updates. I will also take your suggestions there about the course and the channel.
I haven't finished the video, because I want to try it myself first.
I had an idea for the following case.
Elevator is @ floor 5,
Before the doors close, floor 10 is requested, as the elevator begins to move floors 7,6 and 9 are requested.
Would it be a good idea to scan the queue and put all requested floors into a min heap to handle requests between the interval [currentFloor - > requestedFloor]?
Thanks for the comment. You should see the video complete. There are multiple algorithms for elevator system
i have worked 27y in the elevator industry from field engineer to R&D hardware developer, software architect , project manager , R&D manager in two EU MNC.....it would be impossible to make an (OO) design of a an elevator controller in 45 minutes and describe all its nuances....and if that 45 minutes are the potential answer to an interview question at Google , it is very very messy.....i am preparing an elevator (mechatronic) design online course on my own but it is a HUGE topic...you have not cover even 0.01% of all potential elevator features/requirements (some of which even varies by region/country/city)
Thanks for the comment. The goal of this video also was not to design completely in 45 min and done with it. But just to provide food for thought and some hints about what are different things to consider 🙂. In interview also, the interviewer is not looking at you to solve the problem end to end but looking at how you tackle the question.
Your videos are really helpful. I have a suggestion if you could go on low level design like creating iterfaces/abstract classes for different actor and how will you club then in the elevator system class. And how these component will interact with each other. That would be better.
No fake accent, no PJ..just knowledge in the best descriptive way..
Excellent video..
Thanks for the comment 🙂
Nice video but you could have focused more on OOD as well. Like Button -> (Elevator Button, Hall Button) -> Elevator Button (Event Button, Floor Button) -> Event Button (Alarm Button, Fan Button, Light Button, Door Button). Here floor Button will only deal with floor functionality. Same for Fan, Door, Light etc button also. In this way SRP is not violated. Button interface can Have method like action(SystemInterface): void . Here SystemInterface can be extended by two classes ElevatorSystem and AdminSystem. for action methods under EventButton class we can prefer passing action(ElevatorSystem e): void and for HallButton we do action(AdminSystem a): void, bcz it deals on system to decide which elevator to sent on passenger floor.
great comments!
I think the reason that we used enum to represent the { idle, going up, going down} states is because the state space should be only limited to these 3, whereas in the parking lot example there could be many types of parking spots that can be added even after first version of design is done. In the parking lot example, we designed it to be flexible so that when other types of spots are needed, they don't violate the Open/Close principle, but in this one we want the elevator states to be closed and not modified later.
Correct. Thanks for the comment 🙂
@@ThinkSoftware thanks for this Video. Just a question to understand something: is a car full loaded not a state? or "out of service"? even "door open" is different than idle. If the car is full then it should not takes new Hall call... In case of a car "out of service": the dispatcher should not give hall call and "reload" the previous call to other elevator... So, I would like to know, if those example are not States then how do you advice to introduice it in the program? Thanks
but theres no way to fix the enum space. we can add as many as we want
I am new to system design and I cannot explain how much this helped. Thank you very much, Sir!
Thanks for the comment 🙂
I watched many videos on elevator design, but your content and way of explaining is super awesome.
No one will get rejected in an interview if he can explain like this.
Very satisfied. Thankyou very much !!!!!
Thanks for the comment 🙂
I signed into my RUclips account just so I could tell you how useful this video is. Explained so clearly, thank you!
Thanks for the comment 🙂
> big tech companies
This question was asked in client interview which was the last round in wipro recruitment process. I wasn't prepared for that, in fact coming from a tier 4 pvt college i never came across such question. But I did my best, and that was great interview experience. Me and the interviewer both drilled down into elevators for over an hour.
Thanks for the comment
really wipro asked this much are you fresher ?
i wish there were no elevator in this planet
I think you have not tried stairs going to a 10th+ floor building :)
@@ThinkSoftware😂😂😂 now he wishes there were no such tall buildings exid on this planet
@@ssmcs060 and it'll very soon boil down to "I wish there weren't this much population" or ultimately "I wish I wasn't"
Probably the best resource out there to learn LLD.
Love ur videos. Tis is my reasoning for a person class / Car class.
A class is collection of DATA + FUNCTIONALITIES. Here a person has no direct functionality / data. hence no entity needed.
Thanks for the comment
This gentleman is clearly an educator and a very good one at that!
Thanks for the comment 🙂
Thanks a lot for the video. Couple of questions
1. Do we need button class at all? Essentially we are creating InternalRequest and ExternalRequest when press ElevatorButton or HallButton respecitvely
2. For Button class , you drive ElevatorButton class and HallButton class from it. I think we should not have PressDown() in Button class as there is no equivalent in ElevatorButton . In real elevator buttons, there are only floor numbers buttons, help button, door open/close button etc but no up and down
PressDown() is not literally up/down function but a function called when any button is pressed. Recall javascript keydown events.
High quality content. Better than other videos on RUclips
Thanks for the comment :)
I did not read all of the comments below, so maybe someone already mentioned this, but I believe a fourth elevator car state would be "out of service." Your videos are bringing together a lot of loose ends for me. Thank you.
Yes the video cannot be considered as the complete solution.
Really Good Video,
Actually Elevator System Problem is really Complicated problem if we try to dive deep and think.
Thanks for the comment 🙂
I was expecting something like a UML's breakdown/discovery of classes, based on BEC architecture, Boundary, Entity, Controller objects per use-case. Like for example in your first use-case, 'calling elevator', what are the boundary objects, (buttons), entity objects (direction, destination), then a a controller object to carryout this use-case (which essentially responsible for the complexity of this 'calling elevator' use-case). I think your 'elevator system' object is interesting as well, its the dispatcher, may interact with per use-case controller objects, in this use-case to notify the progression of the elevator as it travels. Any thoughts on BEC driven oo design? Thanks.
This Rocks! Not the evelator, but the presentation! I've been wondering about this since college. Now I'm in a five floor building, it all makes sense. What if a vip is coming home to your house in a suprise visit.
I don't see how divide and conquer would help in this scenario. Most people would go from floor 1 to the floor where they live and back. Very rarely you would see people going to other floors from floor x != 1. You could have them change elevator cars midway or so, but that is quite an inconvenience (and it would be very annoying if I had to switch 3 or more cars to reach my floor from the bottom). Maybe an adaptive system based on real-time traffic would work, or maybe a division based on functional areas of the building: office floors, living floors, cafeteria/gym floors etc, but that would entail a lot of extra complexity.
let say when in an idle state, the dispatcher gets multiple requests, in either direction, first, the requests will be divided into going up or down. the dispatcher will first see max no. of requests, and add them into a min-heap and send the elevator closest to the top person who is there at the heap, and will not be idle until the heap is empty now or if the elevator reached either endpoint.
Thanks for the comment. Which algorithm are you referring to?
Thank you so much for this great content. I learn a lot from it.
Glad it was helpful!
It's a wonderful video, please make more of such videos.
Thanks for the comment 🙂
Thanks for the efforts, very well explained.
Thanks for the comment 😊
Thanks for the good content. One point here, no matter what others have covered on this topic, if you are creating a video on it, watchers get intrigued about how you would do it.
A complete UML diagram at least would make it a self sufficient tutorial. Also I didn't get why you need ElevatorMotion interface. How does it fit in between 1. dispatcher and Elevator, 2. Internal button and elevator itself.
That's why UML is important to know what is your design approach
Thanks for the comment
Your info is really good. This information is very useful for those who have searched for this and you have great knowledge about this. I’m really impressed with this.
Thank you so much.
Thanks for the comment 🙂
Great explanation once again!!
Thanks for the comment 🙂
I have seen practically, preallocate the elevators based on floor range and then apply the "Destination Dispatch Algorithm" based on the floor. This ensures Topmost going passenger need to wait due to some low-level floor passenger.
Thanks for the comment
Its very informative and helps to think about system and subsystems
Thanks for the comment 🙂
Learnt a lot from this video! Thank you!
Thanks for the comment 🙂
Excellent , great video !
Thanks for the comment 🙂
Hi Sir, thankyou for making such great content but there are only 2 videos for low level design . Please make more videos. In the paid course also , LLD videos are not there.
Useful
One of best explanations for eleveator design. It was quite helpful.
Thanks for the comment 🙂
@@ThinkSoftware Bro why didn't you delve a lil deeper in the priority queue approach. Maybe that's the nature of how the interviews are conducted. Still a good job done
I bow to your explanation and clarity. Thanks a ton. Extremely helpful
Thanks for the nice words 😊
Nice and very informative video. Please make more videos on object-oriented design.
Thanks for the comment 🙂
Thanks for this wonderful video! I always have problems finding the proper requirements for the system...
Thanks for the comment :)
Before watching the video I was thinking something similar to LOOK ahead eventhough I never heard about it. I would try to do some combination of look but with timestamps along with booleans to decrease waiting time
enums are used to define limited and fixed number of varieties which are impossible to get modified in future as well. For e.g. Days of week, Months of year In case of parking lot there are possible changes of introducing new Spot type in future which have needed modification of existing classes and that goes against the Open close SOLID principle. In case of Elevator type, the direction is never going to change. It can only be up, down or idle even in future.
thanks for the comment :)
After a huge break, nice video with in depth explanation..
Thanks sir.
Thanks for the comment :)
Thank You for this video.Was waiting for something like this.Its amazing.
Thanks for the comment 🙂
Great video and explanation!
Thanks for the comment 🙂
What an amazing explanation!!!!! Hats off to you😀
Thanks
At long last I was able to tackle the problem with some confidence. Excellent video. Thanks very much.
Thanks for the comment 🙂
Great video! I love your explanations!
Thanks for the comment 🙂
Very informative.. 👌
Thanks for the comment 🙂
Awesome explanation of the algorithms! Thank you so much!
Thanks for the comment 🙂
You look like Ashish Nehra. Btw..Very Good Content
Thanks for this video. I really enjoyed it!
Thanks for the comment 🙂
32:43, very interesting. So just to clarify, the hashmap is to handle request made from inside the elevator car, correct?
Scan all floors from 0 - > N, when a button is pressed on a floor, mark the boolean as true
The elevator will move up and then down, it will change its direction when it reaches the 0th and nth floor
Use 2 boolean arrays for the up and down direction, stopping at floors marked true, then marking the floor true, (request served )
Each elevator car also has a hasmap to keep track of the floors it should stop at, adding floors requested and then removing them when request is served.
Thanks for the comment :)
Descriptive and clear explanation. Thanks
Thanks for the comment 🙂
The first part was good but the algorithm part was confusing. And at no in this video did you mention about state of the elevators controlled by the people who are inside the elevator. There would be a number pad inside the elevator where people press the actual floor button. For example, 10 people get in the elevator on floor 2. One of them wants to go to floor 1 and 9 of them want to go floor 100. Essentially it has two key functions: elevator summon and passanger dispatch. You haven't attempted to make any distinction between the two at any point in this video
Thanks for the informative video. Rally appreciate your effort.
Thanks for the comment 🙂
Thank you so much mate. Great Material.
You are welcome 🙂
@Thinksoftware please add some machine learning based system design questions such as ad prediction, search ranking etc. And how to approach these questions and how the requirements change for machine learning problems. Thank you
Thanks for the comment
Thanks you very much!
Thanks for the comment 🙂
Nice explanation and very well explained use of enum.
Thanks for the comment 🙂
thank you for the video,
why you didn't use (or talked) about the state design pattern when implementing the states on the elevator (up, down, idle states) , instead of using Enums ?
is Enum more preferred ?
In this case, we know that we will only ever need 3 states (up, down, idle) and we will NEVER extend this functionality. So enum is sufficient, because we will never extend it.
very useful
very nice presentation..looking forward to more system design topics like airline ticket reservation or movie theatre
Thanks for the comment 🙂. More videos will be coming soon.
Very nicely explained. Keep up the good work! Thanks!
Thanks for the comment 🙂
Nice video....So these are basically disk scheduling algorithms
Yes..sort of.
One of the usecases could be ++ weight is more than assigned..automatic door open with voice/beep..
Thanks for the suggestion
Make a simple video on selection of motor capacity and loading of car to have energy efficiency
Thanks for the comment. This is out of scope of this channel.
My big question is, how are all of these objects tied together to make it all work together ?
Explained in a really simple way and to the Point. I would Like to know If Think Software Team has worked on Witness Horizon Software, as I am working on a Project to Simulate Different Call Strategies for a TWIN Elevator System.
Thanks.
What is an elevator? The ine that gets stuck in the middle. How do we get out?
we need passenger class if we are having maximum load property for elevators.. Each person will have some particular weight that we need to take care of.
How would you know the weight of each person?
There is a whole section about elevator maintenance that you can get into
Thanks for the comment
Let's say if the elevator system is out of order then shoud we add this state in the Enum only.
waoo....!!! this is impressive. :)
Thanks for the comment 🙂
14:30 How will you accurately represent the specifications mentioned at 5:24, such as elevator car load, passenger throughput, passenger waiting time and passenger distribution, if there is no passenger actor involved in the model?
Why we are using ENUM? so the answer is UP,DOWN,IDLE these are the states of the Elevator and it can not be change, so we can say that its a constant property of elevator. In java if we want to define constant ENUM is the best choose.
thanks for the comment :)
Are there really such questions on interviews out there? Puzzle is nice, but seems to complicated.
This shows that you already know about elevator. Also there is no implementation. I would like to see requirement -> implementation. Refine requirement, refine implementation,
what would be the database choice for elevator system
While we analyze use case, should we think from user's perspective ? like you said in video, the elevator can open doors and close doors, but I think it is not from user's perspective, that is what elevators can do, not users. I'd like to know more about it.
Thanks for the comment. What would a user do in elevator control system?
I love it. I would love it more if there were less breathing and saliva noises in between. Good explanation btw
Thanks for the comment 🙂
Frequent saliva swallowing sounds are a bit unsettling..
I had a very powerful microphone I guess 🤔
i love you thank u very very very much !!!!!!
Thanks
Come up with classes & method
Can you make video on FPGA based Elevator controller...with small lift demo using motor
FPGA based elevator controller might be off-topic for this RUclips channel.
Functional requirement mentioned the need to check for the max weight and number of passengers translates to the max weight.. I did not get what we would not need the passenger class in this design as the above are calculated based on passenger object attributes
For the last use case for dispatcher algorithm where the elevator is going opposite direction to passenger, how is it different from the state where the elevator is going opposite direction to which the passenger wants to go? Seems like the same state else we are more inclined to say that passenger is on floor 1 and elevator is moving to any floor which is > 1, the last state did not make much sense to me or I got it wrong.. do let me know..
whats a great video
Thank you Think Software, this was really nice. I've just one question, in SCAN algorithm why we need priority queues when anyway we are using two boolean arrays for going up and down ? As, array indexes are already sorted and we have to look at each index of the array whether its set or not. What is the benefit we are getting by using priority queues?
The boolean array is used only for passengers who want to onboard the elevators. So if it is set for a floor then an elevator will stop at that floor and reset the value. Then the two priority queues or a single hashmap (for each elevator car) is used to store the destination floors that passengers riding the elevator car want to go. The same boolean array cannot be used for this purpose.
@@ThinkSoftware why cant the elevator also use a similar concept and maintain boolean array for destinations? everytime it waits at a floor to drop off pasengers it can be change the array to false and change it back to true when at least one passenger sets that floor as destination. would avoid heapify effort
ruclips.net/video/siqiJAJWUVg/видео.html
For the lookahead in the LOOK algorithm, simply using a bitset is also a good option. 160 floors can fit into 20 bytes. We can test for each byte segment sequentially and from each byte one can access the digits with bit manipulation operations.
thanks for the comment. Such optimization are only need though if we are working on some embedded system with way less memory than the memory that is currently available in current computers.
Sorry but, Elevator are build with embedded system, for reason like: price and ... no risk of Win 10 update while the Lobby is couded :-) Regards.
Great as always. Is is possible make a video on 'how to identify actors', sometimes I get struck and ask "should this entity be an actor?", any help would be helpful.
Thanks for the comment 🙂
I think even Doors would have hall and elevator implementations as when pressed hall button, the hall door should not open until elevator arrives whereas elevator door can open wherever its dispatched to. Am i right ?
all depends on the requirements and how you define the system
Now a days elevator system moves horizontal also so we should have class and not enum for the elevator's states, just a suggestion :) But overall video is good. Please make a video on elevator's class diagram also
thanks for the comment
Where is the class diagram if this is about OOPS
But you omitted what is perhaps the most critical aspect of elevator design... The music!
Keeping some stuff for my audience to design 😉
Could you please explain what the "Priority queues" are used for in the case of the SCAN algorithm?
Because if I already have in the tru array where the elevator has to stop, I don't understand what's in the queues.
Thanks
I was also wondering the same. May be priority queues (min heap for UP, max heap for DOWN) contain the destination floors which the persons inside the elevator might have pressed. Elevator checks these queues in order to drop the people.
I will disagree with the statement that we should not use Enums in cases where we may need to modify them, we never have 100% confidence that things will stay as they are. So instead we just need to use appropriate technics to encapsulate all the logic we are doing with specific Enums in one place or be sure that we will change it we will get error/warning from the not handled cases. In the case with a parking lot having classes is rather for the ability to add there some additional properties like size or specific structural differences.
thanks for the comment..
Dont we need to consider the weight of the passenger? The total weight of passengers should be less thn threshold. I feel we need passenger object
If passenger class is not used, how would we track total weight in the elevator as elevator has weight limit?
How passenger class will help to track weight? Weight will only come from weight sensors.
Are the algorithms inspired from the OS Disk scheduling algorithms?
Yes. Scan algorithm is also popularly known as elevator algorithm.
How we handle Service Mode of the Elevator Car?
what do you think?
Better to replace PressDown() with PushButton() otherwise it will be very confusing to understand what it is going to do.
Thanks for the comment
Without passenger object, how would you determine the available capacity of Elevator ?
You don't need passenger object for that. How will you even know the weight of each individual passenger? You will just keep track of total weight provided to the elevator by weight sensors
Passenger class would have been useful if you have to enforce the weight requirements of the car. How do you enforce it otherwise ?
Thanks for the comment. We are designing the system and not simulation. How will you enforce weight requirements with a passenger class?
If one of the requirements is that we should be able to enforce such a limit than it can be done as you know the number of passengers boarding the elevator car at any time. Makes sense ?
First of all you need a mechanism to identify how many passengers on board or get off the elevator car. Secondly if needed, this can be done via a passenger counter in the elevator car. Why do you need a passenger class?
How do you know the weight of the passenger ? One could argue that if the elevator car refuses to move, the last person to get in should get out. I can think of other requirements but it is beyond scope. I agree we can get away without a class