16. Design Vending Machine | LLD of Vending Machine | State Design Pattern | LLD interview question 

Thanks

thank you

thanks, Yes Shobhit, actually instead of creating new object Singleton object should be used but for easy explanation don't want to include another design pattern and concentrate only State design pattern only. But that can be easily enhanced.

Yes, its in WIP, currently i am adding couple of HLD videos thwn will switch back to LLD

Thank you

Thanks a lot 😊

thank you

Thanks 🙏

Glad it was helpful!

thanks

:) thanks

Yes you are right, later on i thought it would be better to use abstract class instead

this would definitely reduce the code, I think creating multiple interfaces as per ISP is not the right solution here as there would be many interfaces and it would look like over-engineering somehow. Can be done however if the operations are less in number.

@@tarunkundhiya5196 The thing is we can not stop the user from pressing the wrong button, Suppose we are in the Has money state, and if the user presses the dispense button, we must have defined behavior for wrong operation as well. so it is necessary(in this case) that all stated should define all the methods(Intended or default behavior). Hope it makes sense.

@@ConceptandCoding Can you please let me know how to use abstract class method here ??

In my opinion, default methods were introduced in Interface, so that new functionalities can be added to implementers without breaking the existing contracts. If want to force error, have default methods that throws exception and implementers will override only required default methods. This way implementers will be a lot cleaner.

we can change interface to abstract class and implement the method (that throw exception) in base class and child class which want to implement can override it.

It's not breaking Interface Segregation Principle. What Interface Segregation principle says : You should not force the Concrete class to implement the method. So lets understand this Line with an example: I have an interface Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) And say Duck has method "quack" , "fly" and "Swim". Now lets say, i am adding one more Concrete Class, "Rubber Duck", Now it breaks Interface segregation Principle, why because Rubber Duck can never Quack and never Fly. But still we are forcing RubberDuck class to implement "quack" method and fly method and throw exception. Rubber Duck can NEVER quack and fly. Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) -> Rubber Duck (Concrete class) *breaks interface segregation principle But in Vending Machine, all are the valid operations of a Vending Machine Interface, Vending Machine can do all operations, just it depend upon the state, but say in future we can extend and allow some operation in existing state right. Hope it clarifies.

@@ConceptandCoding May be it is better if we make all operation as Commands and while executing command check if Vending Machine is in allowed state or not. This will help us in reducing duplicacy.

I agree, the contracts needs to be attached to Vending machine. Its a standalone box. State machine is an overkill.

yes you are right, we can make it more better by changing interface to abstract class and in abstract class, we can implement the method and throw exception there, now any child class wants to override the functionality, can override it else not required

Thank you

thanks Vijay. Pls do share it with your connections.

​​@@ConceptandCoding udit agarwal, think software.. channels jaise high quality content hai ye❣️ I'll share 👍

thanks a lot Vijay, really thank you for your kind words. Its a new channel so reach is less, so this comment really means a lot to me.

thanks

Hi Elliot, pls start from the second video, SOLID principles, its the beginning of the playlist. Vending machine is the latest video, thats why i kept it on top, i will move it to the bottom of the playlist

@@ConceptandCoding ok

thank you

Ack, i will reply tomorrow.

Sure Prashant. HLD and LLD are very different. HLD is at top level, how different components put together for any application like Load balance, Microservices, Cache, What DB to use etc etc. But LLD is OOPs concepts more close to Coding. Objects involved, classes, their relationship. LLD does not bother about what DB to use, Load balancer, cache, CDN and all. But if you have doubts we can discuss more.

Thank you

thanks Mustafa for input

Hi, could you pls check this live session which i took ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE--UjjfzJ574w.html Look for interface segregation part, I think it will clarify your doubt if not let me know

hi @@ConceptandCoding, I gone through the video, got the scenario thanks for the prompt response.

thanks Sachin

yes you are right, we can make it more better by changing interface to abstract class and in abstract class, we can implement the method and throw exception there, now any child class wants to override the functionality, can override it else not required

Right, same i did in ATM design. You are right buddy

Both are very valid questions: 1. Yes, it is important to empty the coins list and then change state to idle. 2. I don't think this check is required since there is no concurrency, and the user can actually see that product is available

For the 2nd part, we can refund the money, so the vending machine will go from selection state to the idle state, after returning the money to the customer.

It's not breaking Interface Segregation Principle. What Interface Segregation principle says : You should not force the Concrete class to implement the method. So lets understand this Line with an example: I have an interface Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) And say Duck has method "quack" , "fly" and "Swim". Now lets say, i am adding one more Concrete Class, "Rubber Duck", Now it breaks Interface segregation Principle, why because Rubber Duck can never Quack and never Fly. But still we are forcing RubberDuck class to implement "quack" method and fly method and throw exception. Because these feature RubberDuck can NEVER have. Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) -> Rubber Duck (Concrete class) *breaks interface segregation principle But in Vending Machine, all are the valid operations of a Vending Machine Interface, Vending Machine can do all operations, just it depend upon the state, but say in future we can extend and allow some operation in existing state right. Hope it clarifies. Yes one improvement we can do is instead of interface we can take abstract class and all the throw exception repetition we can avoid

we can use abstract class instead of interface and provide the default implementation there, so that no child class need to implement the method unnecessarily

yes we can restrict that in our design.

interface can be changed to Abstract class (where we can implement the method, so that all child classes no need to override them) yes it looks similar but they solve different purposes.

Maybe we can just have a handle function in the State Interface. And accordingly the other states should be implemented.

Thats true for all LLD questions Tushar, for all LLD you need some whitebording, and generally after discussion with Interviewer you can use your pen and notebook and speak out loud or express you thought with sample class making and speak out the relationship. But if you have ipen then you arw in advantage though

change the interface to abstract class . and we can provide default implementation in the abstract class itself

we can change it to abstract class and provide a default implementation there so that no child class need to implement it

@@ConceptandCoding But still those default implementations will be redundant code in all the concrete classes?

Yes we can take abstract class instead.

User is not calling the dispense product method, it is a chained method call from the selection state

could you please elaborate why? we can discuss

I have already covered, pls check the complete playlist buddy

Hi Mohit, based on the State design pattern approach, could you please try to implement the respective changes which you have mentioned. If you get stuck, we will definitely discuss

Hi Sarvesh, in ATM i did use COR pattern. But see when COR can be used when you go sequentially and check "hey can you fulfill the request, if not go to next", so in vending machines, currently we are directly putting slot number but let's say if there is a requirement that we have to go each slot sequentially and see, if request can be fulfilled then we have to use CoR for implementing that part. So it will become state + COR like an ATM.

@@ConceptandCoding Ohh..ok. Now it is clear. Thanks a lot!!

​@@ConceptandCoding Hi Shreyansh, what in the case of giving the coin changes in Vending Machine, in that exact state we can apply the CoR. As it is almost act like an ATM machine but in a different way.

@ConceptandCoding

It's not breaking Interface Segregation Principle. What Interface Segregation principle says : You should not force the Concrete class to implement the method. So lets understand this Line with an example: I have an interface Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) And say Duck has method "quack" , "fly" and "Swim". Now lets say, i am adding one more Concrete Class, "Rubber Duck", Now it breaks Interface segregation Principle, why because Rubber Duck can never Quack and never Fly. But still we are forcing RubberDuck class to implement "quack" method and fly method and throw exception. Rubber Duck can NEVER quack and fly. Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) -> Rubber Duck (Concrete class) *breaks interface segregation principle But in Vending Machine, all are the valid operations of a Vending Machine Interface, Vending Machine can do all operations, just it depend upon the state, but say in future we can extend and allow some operation in existing state right. Hope it clarifies.

@@ConceptandCoding doesn't this violate liskov substitution principle. Now we can't replace any start object with another state object?

@@ConceptandCoding In SOLID principles, I think this is breaking Liskov Substitution Principle, which states that we should be able to replace objects of same types without breaking the functionality. I have an alternate solution for this, we can have a State Interface and then specific State Interfaces for each type of state. State Interface(Base Class), should contain only one method, i.e isActive: which should tell weather the state is simply active or not). In vending machine flow or any state transition flow, only one state can be active at a time. Improvement is, instead of forcing each state to implement a not required method, we can simply check if the state is active or not, whenever there is an operation we want to trigger on that state, if state is not active we simply show a message/exception that this operation is not allowed at the moment. Handling of operation can be governed by a runner method. The responsiblity of runner method will be to change state of the vending machine based on the operation chosen by the user, and call required method of the state, only if the state is active. (Let me know if there is any drawbacks of this approach.)

@@ConceptandCoding But this doesn't hold true for all the states, for eg. We can never refund money from the idle state. So ideally some segregation of methods should be there by creating some more interfaces

It's not breaking Interface Segregation Principle. What Interface Segregation principle says : You should not force the Concrete class to implement the method. So lets understand this Line with an example: I have an interface Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) And say Duck has method "quack" , "fly" and "Swim". Now lets say, i am adding one more Concrete Class, "Rubber Duck", Now it breaks Interface segregation Principle, why because Rubber Duck can never Quack and never Fly. But still we are forcing RubberDuck class to implement "quack" method and fly method and throw exception. Rubber Duck can NEVER quack and fly. Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) -> Rubber Duck (Concrete class) *breaks interface segregation principle But in Vending Machine, all are the valid operations of a Vending Machine Interface, Vending Machine can do all operations, just it depend upon the state, but say in future we can extend and allow some operation in existing state right. Hope it clarifies

@@ConceptandCoding yeah got it, thank you 👌

right, in comment section i have mentioned this to avoid duplication

Can you provide the UML git link or elaborate more information, how you will gonna proceed with this design patterns Neelansh

It's a youtube option, generally at home page you should be able to see Join button

Noted. Let me add it in my todo list, thanks for sharing.

we can change the interface to abstract class and provide the default implementation there. so that child classes should not unnecessarily throw exception.

It's a tradeoff for this design. We can't always design keeping all the design and SOLID principles in mind.

It's not breaking Interface Segregation Principle. What Interface Segregation principle says : You should not force the Concrete class to implement the method. So lets understand this Line with an example: I have an interface Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) And say Duck has method "quack" , "fly" and "Swim". Now lets say, i am adding one more Concrete Class, "Rubber Duck", Now it breaks Interface segregation Principle, why because Rubber Duck can never Quack and never Fly. But still we are forcing RubberDuck class to implement "quack" method and fly method and throw exception. Because these feature RubberDuck can NEVER have. Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) -> Rubber Duck (Concrete class) *breaks interface segregation principle But in Vending Machine, all are the valid operations of a Vending Machine Interface, Vending Machine can do all operations, just it depend upon the state, but say in future we can extend and allow some operation in existing state right. Hope it clarifies. Yes one improvement we can do is instead of interface we can take abstract class and all the throw exception repetition we can avoid

wacom tablet

Many companies do ask for Coding. If UML is correct and interviewer is okay, then coding completion is not that important. Even we write the code partially after UML, chances are still high for acceptance. I refer "head first design pattern" book for design patterns. Questions solving that comes with an experience :)

@@ConceptandCoding Thanks. Just one more question How necessary it is remember the signs for association, generalization and all those things? i am particularly talking about the arrow symbols

Hi Pankaj, the same doubt i have cleared in the Live session ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE--UjjfzJ574w.html Pls have a look, your doubt will get cleared

yes we can, and its much better than interface

Can you please tell me the usecase of two states of machine at the same time?

we can change it to abstract class and implement the default method there. then child classes no need to implement it unnecessarily

you can also design vending machine using chain of responsibility, do try it out. there are many ways to design one system.

Ack of the question.

I have the same question. I think here, we can instead make State a concrete class and use strategy pattern to inject different behaviours of the different functions in the state class.

yes you are right, we can make it more better by changing interface to abstract class and in abstract class, we can implement the method and throw exception there, now any child class wants to override the functionality, can override it else not required

LLD in C++ does not matter Ayush. If you understand the object relationship and UML diagram, you can code in any language

in hasMoneyState, money is already there in the machine, now selection of product can be done or refund. Cash Insertion done in Initial/Idle state

@@ConceptandCoding ok got it. In state wise operations, u had written insert coins option under hasMoney state, it was confusing. thanks for the clarification.

Hi, yes you are right, we can avoid this code repetition, either using abstract class too. But you can definitely try to implement it with strategy pattern, as there can be many ways to implement it, eager to see your solution and then we can discuss more on that

@@ConceptandCoding thanks for the prompt response,sure I ll create a solution and then we can discuss on that Thanks, Jainam

It's not breaking Interface Segregation Principle. What Interface Segregation principle says : You should not force the Concrete class to implement the method. So lets understand this Line with an example: I have an interface Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) And say Duck has method "quack" , "fly" and "Swim". Now lets say, i am adding one more Concrete Class, "Rubber Duck", Now it breaks Interface segregation Principle, why because Rubber Duck can never Quack and never Fly. But still we are forcing RubberDuck class to implement "quack" method and fly method and throw exception. Because these feature RubberDuck can NEVER have. Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) -> Rubber Duck (Concrete class) *breaks interface segregation principle But in Vending Machine, all are the valid operations of a Vending Machine Interface, Vending Machine can do all operations, just it depend upon the state, but say in future we can extend and allow some operation in existing state right. Hope it clarifies.

@@ConceptandCoding I still believe making smaller interfaces like S1,S2,.... and then utlizing them (multiple inheritance) would be better way to go. This will take into account in future we can extend and allow some operation in existing state right.

@@ConceptandCoding no it tells " clients should not be exposed to methods it doesn't need". So I feel the 1 interface with bunch of methods is not needed. It should have the methods needed by all childs only.

gitlab.com/shrayansh8/interviewcodingpractise/-/tree/main/src/LowLevelDesign

Naman could you please elaborate, why you think its breaking Interface segregation principle

@@ConceptandCoding It is breaking interface segregation principle since not all the methods of the interface are getting used in the concrete state implementations. We are simply throwing exceptions for the method we are not using. And according to the principle we should not force a class to implement methods it does not use. Solution could be to separate the methods belonging to a state in a separate interface.

@@parissweetheart96 Throwing exception or default behaviour is not a dummy implementation of the methods in a vending machine context. Here we are exposing vending machine to a customer and the customer can choose to dispense product in an ideal state. So we need a default/exception implementation here. So essentially its not breaking interface segregation !

It's not breaking Interface Segregation Principle. What Interface Segregation principle says : You should not force the Concrete class to implement the method. So lets understand this Line with an example: I have an interface Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) And say Duck has method "quack" , "fly" and "Swim". Now lets say, i am adding one more Concrete Class, "Rubber Duck", Now it breaks Interface segregation Principle, why because Rubber Duck can never Quack and never Fly. But still we are forcing RubberDuck class to implement "quack" method and fly method and throw exception. Because these feature RubberDuck can NEVER have. Duck (Interface) -> MallardDuck (Concrete Class) -> DomesticDuck (Concrete Class) -> Rubber Duck (Concrete class) *breaks interface segregation principle But in Vending Machine, all are the valid operations of a Vending Machine Interface, Vending Machine can do all operations, just it depend upon the state, but say in future we can extend and allow some operation in existing state right. Hope it clarifies.

I also have same doubt as Samarth. Thanks for clarifying Shrayansh

we can change the interface to Abstract class and implement a method there so that all child classes will not override the method.

change the interface to abstract class and provide the default method implement there

@@ConceptandCoding I read these patterns but wasn't sure where & how to apply it,Going throught ur playist, liked ur approach of using an practical example & solving with a pattern..it is what i was looking for... Thanks for ur crystal clear explaination.

Pls check the Design ATM video, i have covered it in that i have used both, it will clarify your doubt

we can. depending upon the requirement. in chain of responsibility, machine has to check each slot one by one and see if request can be fulfilled or not. but it can be done

@@ConceptandCoding Got it, thanks!

change the interface to abstract class and provide default implementation in it. so that child classes need not to implement it

@@ConceptandCoding and then we can just override the default implementations in child classes of only those state which is needed ?