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

[@namansaraswat9691]

This is by far one of the best and very easy to understand lld video I have seen.

[@shobhitarya1637]

Wow..This is a very informative and detailed low level design video. Thank you Concept && Coding. There is one thing instead of using creating state using new operator, we can use controller containing objects of all states. Because using new operator, every time vending machine run, new objects created.

[@ConceptandCoding]

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.

[@AkashShukla-ny9wu]

Liskov: subclass should extend the capacity of parent class not narrow it down. Are we following this principle on state pattern

[@ajazahmed5079]

nicely explained, got to know about State Design Pattern. Please keep uploading such LLD Questions for more understanding

[@ConceptandCoding]

Thanks

[@ayushvida]

Thanks a lot for detailed explanation

[@ConceptandCoding]

Glad it was helpful!

[@HarshChoudhary-v9v]

One of the best video i have seen so far.

[@aalokkumar5662]

Really nice video and your explanation is better than others many one.

[@ConceptandCoding]

Thank you

[@tarunkundhiya5196]

Nice Video! One point ISP from Solid principle says "Clients should not be forced to depend upon interfaces that they do not use“. But we are having those different states implement the State Interface which are having all the methods which are not applicable to them. I think we should also find a way to fix that. But good content. Thanks!

[@ConceptandCoding]

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

[@tarunkundhiya5196]

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.

[@sourabhchoudhary7289]

@@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.

[@mohammadkaif8143]

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

[@bhaveshshah3405]

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.

[@anirbanhaldar4640]

Wow! very informative and detailed LLD video..keep going! 👏👏👏

[@ConceptandCoding]

thank you

[@arnabbhattacharya825]

What if we select the product first and calculate the money required, and then insert the coins, then exception handling of insufficient money might be easier?

[@shruthakeerthis4549]

Very well explained !! I have two doubts, please ignore if this is a trivial one: 1)Once we refund the coins, should we update the coins list too ? 2)in dispense Product method, should we check if the item customer asked gor is available or not before updating the as sold out ?

[@santosh_bhat]

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

[@rashidsiddiqui4502]

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.

[@PujaSingh-qg5ln]

Thank you. Very well explained and easy to follow and understand.

[@HariSarvotama]

Thank for the informative videos . Really helpful while preparing for the interviews. I have few doubts here . 1) in this the SOLID principle we mention that we shouldn't make classes which we don't use but in the State Design pattern , we are creating a lot of classes just to throw exception . is it optimal or accepted in the industry ? Need your opinion on this . Thank you

[@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.

[@akshitbansal5651]

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

[@ThePriyeshpandey]

@@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.)

[@dangerousstrikercr7731]

@@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

[@mloki9201]

Whenever we go to idle state we initialize coinsList of vending machine as empty. So there is no way that vending machine can store coins received from multiple customers. Shouldn't we have 2 variables in Vending machine class. 1. overallCoinsList 2. currUserCoinsList So when we refund full we can just empty currUserCoinsList. And if we don't refund, we can add currUserCoinsList to overallCoinsList. PS: Thanks for making LLD videos. They are super helpful :)

[@ConceptandCoding]

thanks Mustafa for input

[@ritwik121]

Thanks for all the lld videos. Hope you will add more videos to your ongoing LLD Playlist.

[@ConceptandCoding]

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

[@nishantlakhara4127]

Very easy to understand explanation

[@akankshagaur845]

Very beautifully and conceptually explained.

[@ConceptandCoding]

Thanks a lot 😊

[@harshinredzone]

Ye badhiya tha Guru 😍

[@ConceptandCoding]

:) thanks

[@karanbangia14]

Hey, one question why are taking money before placing order, doesnt this adds more complexity? we should select product then collect money

[@Mohit_Gupta24]

One observation: Instead of creating a new state object on every state change operation, we can instantiate them in the Vending machine class constructor. Also, the vending machine itself can have these operations as its behaviour and delegate to the state, instead of getting the state from vending machine in the main class. So, the vending machine delegate the request based on the current state without knowing much to the client(main class here).

[@pritishn6350]

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

[@elliotalderson4333]

As a an absolute beginner I only understood the first half. Can you elaborate the second half concepts such as how you are structuring the java code and why in such way? It wud be very nice if you make video on absolute basics for beginners such as "LLD pre-requisite" video.

[@ConceptandCoding]

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

[@elliotalderson4333]

@@ConceptandCoding ok

[@AishaSharma-pn8fl]

I remember you saying that chain of responsibility pattern is used to design ATMs, Vending Machines and logger. Why haven't we used chain of responsibility here then?

[@ConceptandCoding]

we can, but i want to demo state design pattern here, so vending machine can be done via state pattern too. pls check ATM design, i have used both State and Chain of responsibility pattern

[@nikhilmadaan29]

Best so far

[@saksham483]

You are creating 1 interface with all operations. The class implementing the interface has to override all methods regardless of whether that operation is needed in that class or not. This goes against the Interface segregation principle.

[@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.

[@ayush146235]

@@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.

[@satyamanand4391]

​​@@ConceptandCoding Then in that case we should have created State as abstract class and have some default behaviours defined for all the methods. Now each states need to only override the methods that it supports. By adding all the methods to a single interface here it is indeed violating interface segregation principle.This approach strikes a balance between code reuse and adhering to design principles

[@LokeshRajput-qw9il]

​@@satyamanand4391after java 8 we can have default method implementation in interfaces also

[@LokeshRajput-qw9il]

​@@ayush146235didn't understand this, can you explain

[@shivamyadav4846]

Hi, as this is failing ISP rule of SOLID. How I am thinking to implement it. in State we have only Single method handleRequest(event); all states will implement this. And we have an service Class where all vendling machine function will be defined. State class will have this service class obj. so in perticular state we can use switch case according to req obj and default will be this req can't be served in this state.

[@nithishkumars1657]

dont you think it will become a strategy pattern. I too have the same doubt. For sure, the interviewer will ask the violation of SOLID principles here.

[@santhoshkumar-rx2js]

Thank you Shrayansh.

[@pietech1694]

The video content is quite good.... Please add the git link for free video so that we can understand the code base in better way.

[@jainamshah3691]

Hii shreyansh What if there is one operation that is always available in each state , then there will be code repeatition , right? And if there are multiple such operations then there ll be huge code duplication So i thought can we use strategy design pattern under a state design pattern Also i am not able to understand how we can use strategy here under a state.. Thanks, Jainam Also do you have any doubt stream like telegram or some social or youtube comment is the only stream for asking doubts

[@ConceptandCoding]

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

[@jainamshah3691]

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

[@santosh_bhat]

Very good explanation and design, i believe we could change the state to HasMoneyState if Vending Machine encounters that the required amount is less than inserted coins so that user can insert more coins or should we refund and throw exception like we do. As a whole i get the intent State pattern is solving.

[@ConceptandCoding]

Thank you

[@LOVEPREETSINGH-ft6nd]

nicely explained . But i have one doubt , why can't we use the abstract class instead of interface and move all default implementation to the abstract class so that we can avoid the code duplication.

[@ConceptandCoding]

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

[@vijaypatneedi]

Great content, maza aagya..

[@ConceptandCoding]

thanks Vijay. Pls do share it with your connections.

[@vijaypatneedi]

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

[@ConceptandCoding]

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.

[@saiv-c5h]

since in java class can implement multiple interfaces, we can create separate interface for each function in state class and can provide them default implementation, and states can implement only required interfaces and in this way it can satisfy liskov substitution principle and interface segregation principle. Correct me if i am wrong guys ?

[@ConceptandCoding]

@@saiv-c5h right, and I have mentioned in comment section too that this can be improved same way you mentioned

[@saiv-c5h]

@@ConceptandCoding thanks for confirming this shreyansh. This was indeed a best explanation i have ever seen till now

[@sunny0287]

Great Explanation, easy to understand for any one .... One Question Is this State design pattern is not violating the SOLID principle [Interface segmented principle] ??

[@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

[@sunny0287]

@@ConceptandCoding yeah got it, thank you 👌

[@anandrana7340]

Thanku Bhaiyaji ...such a wonderful content as always , can we make another class for fillUpInventory and displayInventory methods to follow Solid Principle?

[@ConceptandCoding]

Ack, i will reply tomorrow.

[@Mona_yadav27]

hi shrayansh, This is awesome explanation of the LLD vending machine, just a quick question . I may sound dumb , but as per solid principle. No child class should be forced to implement unnecessary method of an interface. as per this, when we are designing implementation of state interface method we are actually forcing the child state concrete classes to implement other. is there a way we can avoid that . Thanks in advance for your response.

[@ConceptandCoding]

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

[@shriharikulkarni3986]

19:15 Shreyansh, if we throw exception in concrete class , then it violates interface segmentation principle right, don’t implement unnecessary methods. Is state design a good pattern?

[@ConceptandCoding]

We can have abstract class instead of interface

[@shriharikulkarni3986]

@@ConceptandCoding even then in concrete class we should throw exception only no

[@ConceptandCoding]

@@shriharikulkarni3986 in parent class itself we can throw exception, and which ever child want to override the behaviour they can override that method

[@WasteMaterial-vr3qe]

I am impressed 😄😅

[@shashankmishra484]

Hey, thank you for the great content I have few questions 1. The part of UML diagrams and part of actual code with main function you have shown, are both needed to be covered in an interview? Or we showcase and discuss the UML and just verbally tell about the design patterns that can be used? I was given vending machine LLD for half hour, not sure if the whole working code can be written in half hour along with drawing UMLs 2. Follow up on above, is this LLD or machine coding 3. Where do you study all these? educative is the best source I know but it purely concentrates on the UML and not on possible design patterns that can be used Please keep uploading. If you upload faster I will be able to crack my next week's interviews 😛

[@ConceptandCoding]

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 :)

[@shashankmishra484]

@@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

[@Mona_yadav27]

Thank you so much . This helps 🎉

[@ayushupadhyaya7656]

Returning the change to user can have follow up question in form of famous coding question-> Coin change

[@shubhamtiwari7704]

Hi shreyansh, How to decide which feature is object there are many posibilities......while discussing the rough flow you generally use this terms lets decide objects......please reply

[@amitgupta-or5nm]

Nycly explained

[@ConceptandCoding]

thanks

[@darkstudio3170]

Really well explained. Thanks a lot

[@ConceptandCoding]

thank you

[@nithishkumars1657]

For sure, the interviewer will ask about the violation of SOLID principles here. I also have the same doubt. Be preapared for the followup questions. OpenAI Justification: The Liskov Substitution Principle (LSP) and the Interface Segregation Principle (ISP) are indeed important principles in object-oriented design. LSP states that if a program is using a base class, then the reference to the base class can be replaced with a derived class without affecting the functionality of the program. In the context of the vending machine design, if a state (base class) is replaced by its specific state (derived class), the functionality should not be affected. If a derived class is restricting the functionality of the base class, then it might be violating LSP. ISP, on the other hand, states that no client should be forced to depend on interfaces they do not use. This principle is about business rules to clients that shouldn’t know about. If a class is forced to implement an interface and provide implementation to methods that it doesn’t use, then ISP is violated. In the context of the vending machine design, the State interface might seem to violate the ISP because it declares methods that may not be meaningful for all states. However, it’s a common situation in the State design pattern. If you find this to be a problem, you could consider breaking down the State interface into smaller, more specific interfaces. But, this might complicate the design and make it harder to understand and maintain. Remember, design principles are not absolute rules but guidelines. Sometimes, they might seem to conflict with each other, and it’s up to the designer to make trade-offs based on the specific context and requirements.

[@ConceptandCoding]

rightly pointed out, we can change the interf to abstract class, so that child class should not implement the method unnecessarily.

[@tejasshaha6629]

Great explanation. Thank you.

[@ConceptandCoding]

Thanks 🙏

[@amiyamishra9858]

Hello Shrayansh,Thank you so much for the nice explanation.One enhancement I can think of ,Please correct me if I am wrong: we should update the coinList of VendingMachinr to empty after dispensing the prouct or after doing refund/change else during next time calculation for amountPaidByuser will be wrong..

[@gyanaranjanmallick9714]

Hi Shreyansh, I have one small query - 1. In your "SOLID principle" video you took the example of restaurant employees, waiter and chef to explain "interface segmented principle" so that chef doesn't have to implement waiter's methods and vice versa. In this case of vending machine states, should we follow the same way and implement different methods for different states? Or is there any particular reason because of which, it doesn't really matter if we follow "interface segmented principle" or not in this particular vending machine case. Thanks, and really appreciate your work.

[@ConceptandCoding]

Ack of the question.

[@ayushagarwal2504]

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.

[@NeverGiveUp186]

Hi Shrayansh, great explanation as always!! I had one doubt. In the video on Chain of Responsibility (CoR) pattern, you had mentioned that we would be using CoR pattern for Vending Machine/ ATM type questions. But in this question, you have used State Pattern🤔. Can you please explain a bit about the choice of pattern selection? Thanks!

[@ConceptandCoding]

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.

[@NeverGiveUp186]

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

[@paraskhare8116]

​@@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.

[@debjyotichattopadhyay6679]

This is really amazing and very informative solution, but adding all the methods in interfaces (even those methods that are specific to certain states) will violate the I of the S.O.L.I.D principle, correct me if i am wrong

[@ConceptandCoding]

we can change it to Abstract class and provide default functionality there

[@Naman-u7q]

You said that we need machine object in all states, but why HasMoney and SelectionState doesn't have the machine object?

[@BTECE_RajdeepSinghTanwar]

Great explanation!! I have 1 doubt, why do we need to provide codeNumber in dispense product method, the product is already choosen so we should store the choosen codeNumber in vending machine only. Otherwise there is chance that wrong item get dispensed by calling dispense product with wrong code number. Correct me if I'm wrong.

[@rv0_0]

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

[@MohitSingh-br7ud]

Shouldn't the ideal state should go to the select product state first and according to the product selected(is not sold out) we should insert coins? Also for the insertion of coins let's says product was of 25rs and I have 3 coins of value 10, in that case, product should be dispensed along with 5rs as a refund, and If I have not inserted the coins making the sum >= 25 the vending machine should keep on blinking and ask for money or should give the option to cancel and refund. Also when the product is going to expire or when the freq of that product is low then a notification should be sent to the owner. Actually, that's the exact question I was asked in Agoda (Bangkok Thailand location). I was stuck at the blinking part of vending machine after product selection. How would you have approached it?

[@ConceptandCoding]

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

[@prashantgupta6160]

Hi Shrayansh, I found your video very informative. Can you make a video on HLD and LLD of one system like vending machine itself, what would be HLD for this. I get often confuse what to tell in HLD and what to tell in lld round, should I discuss API contracts / DB design in LLD round or not... so there is a disconnect between HLD and LLD, can you please make a video in this topic as well.

[@ConceptandCoding]

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.

[@shivshankar5717]

Correct me if i am wrong but I dont think the State interface which you made needs to have all those function, it violates the Interface Segregation principle and Liskov Substitution principle of SOLID principles, like for example while in idle state to have refund function is meaningless and also by adding the exceptions while defining function limits the functionality which shouldn't be done as per Liskov Substitution principle.

[@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. Yes there might be different ways to implement, but i used this example to explain state design pattern, hope that pattern is clear?

[@shivshankar5717]

@@ConceptandCoding Got it, so the crux of the story is that it doesn't break ISP as the vending machine itself is providing those options, we are not forcing it . Thanks man , great content. Keep doing the good work. :)

[@DeepakKumar-oc2zl]

Awesome Explanation of LLD. As you have created Interface which have all abstract methods within single Interface. As per my knowledge, It is violation of SOLID Principle. Can we optimize it in precise way?

[@ConceptandCoding]

Yes we can take abstract class instead.

[@siddhantgupta3050]

doesnt this break liskov substitution principle?thanks for great videos!

[@ConceptandCoding]

Could you please elaborate how?

[@mission_India_2025]

@@ConceptandCoding The interface you created had all methods for all states. That means you have to throw exceptions on some methods in few implementations. That made the child classes not fully replaceable for its parent. Also it violates Interface segregation principle. As its LLD interviewer if catches it then it would be a negative

[@vishalkumar-bz5mq]

Hi just one doubt throwing exception from state classes will voilate the Liskov Substitution Principle right.

[@yashbansal2526]

Great Content

[@ConceptandCoding]

thank you

[@akashchakrabortty2431]

Hi Shrayansh , Thanks for explaining it so clearly.🙂 Just having a doubt- Instead of writing a concreate class of each state where others will throws exception, can we make it as an abstract class?

[@ConceptandCoding]

yes we can, and its much better than interface

[@abhijitmandal9531]

Hi Shrayansh, very nicely explained thank a lot...just a doubt, when we are implementing State interface, we are throwing exceptions in child for some methods (throw new Exception) here are we not violating Liskov Substitution Principle.

[@ConceptandCoding]

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

[@prernapundir8020]

Hi Shreyansh, I just had one doubt: shouldn't the state transition from one state to another be done by vending machine classe? Something like this individual state should just change the status of the machine, and on that basis, switching to a particular state should be decided by the vending machine class, so that state shouldn't create the object of the transition state every time. Just create the object once in the vending machine and pass it on and if so can we use factory method toe create the objects of states. Please correct me if I'm wrong here.

[@souvikpodder9515]

Hey, The tutorial is of great help clearing most of my doubts in this design pattern. Thanks for your amazing content. I have a doubt while implementing the State implementation we are having lot of methods which we are not implementing and throwing exception, but according to the Implement segregation principal in SOLID design we should not be doing so. My question is why are we not using the common interface for the operations where we don't need to implement all the other unrequired operations?

[@ConceptandCoding]

Hi, could you pls check this live session which i took kzbin.info/www/bejne/Y4bNm5mwf5pqatk Look for interface segregation part, I think it will clarify your doubt if not let me know

[@souvikpodder9515]

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

[@amanjain7111]

Seems fine, just one issue. It violates the Interface Segregation principle for all the states, as we all the states need to implement all the methods of State interface, instead it should implement only one. What could be done for that?

[@amanjain7111]

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

[@tomorrowcut]

Hi Shrayansh, Can you please help me with an answer?? Why we are not using chain of responsibility design pattern here?? .. and what’s the trade off between the two??

[@ConceptandCoding]

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

[@tomorrowcut]

@@ConceptandCoding Got it, thanks!

[@amanchoudhary9107]

Does initialising the ItemShelf in the inventory class makes sense. Isn't it breaking the S.R.P, Inventory should be worried about just managing the inventory not maintaining the shelf and there initialisation logic.

[@UntamedRogueMavrick]

Hi Shreyansh, I liked this session very much. I have one question here, whenever we are changing the state, we are creating the new Object of the state and passing it to setter. And if users are more, more and more state impl object will be created. Can we improve this part of code?

[@AyushAgrawal-qm1tr]

Great content 😀..Can you also share some resources for lld in c++ also

[@ConceptandCoding]

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

[@sachinjindal4921]

Really Good

[@ConceptandCoding]

thanks Sachin

[@bipuljee2996]

very well explained brother, would like to have your take on elevator system.

[@ConceptandCoding]

I have already covered, pls check the complete playlist buddy

[@himanshijain8230]

Hi Shreyansh, i have one doubt, in the chain of responsibility design pattern video, you said that in case of vending machine design we should the pattern but here you are solving it using state design pattern. So exactly which one should we use?

[@ConceptandCoding]

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

[@dineshhardasani3414]

Hi, I think the interviewer might not accept this solution because we are duplicating code here. In this flow, we are adding duplicate code for some interface functions, like refundFullMoney, in both SelectionState and HasMoneyState.

[@ConceptandCoding]

we can change it to abstract class

[@dineshhardasani3414]

@@ConceptandCoding Then all classes will have that function, such as refundFullMoney, and we need to override it where we don't want to allow refundFullMoney

[@throxe]

Can you kindly make an English version of this Please.. The video is not really useful for some of us English language speakers cos it's mostly in hindu It's such an interesting LLD Design example and rare to find online at this depth and coverage Thank you

[@ConceptandCoding]

Hi Throxe, i understand that, and thats why i have switched to English and all my videos are now in English only. Regarding this one, i will see, if i can add subtitle or upload in English (in Live LLD Playlist)

[@ebtasamfaridy9137]

Doesn't this break Liskov's substitution of solid principle as some states don't implement all methods defined in the interface or base class ?

[@ConceptandCoding]

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

[@Stockfundamentalstelugu]

I think in state design we are not following the interface segmentation as we said in SOILD right?

[@ConceptandCoding]

could you please elaborate why? we can discuss

[@rajeevnayan9672]

@shreyansh, In this design pattern for state interface, Isn't it violating SOLID (interface segregation principal as each concrete class has to implement all the methods).

[@ConceptandCoding]

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

[@sarveshrawat1462]

Hey Shrayansh, Doesn't this State Design Pattern violate 'I' principle of SOLID. Why we are implementing methods of a interface which we really don't need to implement.

[@ConceptandCoding]

good point buddy, we can change the interface to abstract class and implement the method with default functionality.

[@GateCSE280]

Hey Shreyansh, i have one doubt. This pattern working is nearly similar to what we learned in proxy and chain of responsibility design pattern. Why I said proxy, because if you see we can create layers and the object of mext layer will be created only when the current layer is finished. example: First layer is idle; waiting for user input Second proxy layer: insert coin; once user press submit, go to third layer that is choosing product. Am I correct? Also this pattern, is violating the I of solid principle. Interface segregation. Because different states are unnecessarily inherenting the not required functions?

[@ConceptandCoding]

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.

[@ChandanKumar-rl6df]

If you are keeping all the methos in Interface and respecting concrete class will implement properly only required methods and throw exception from other methods. Don't you think we are breaking Interface segregation principle from SOLID?

[@ConceptandCoding]

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

[@mintu591]

Hello sir, I've a doubt , You taught in the SOLID principle lecture, L says Interface should be such that there implementation class should not implement unnecessary function they do not need but in vending design machine video we are overriding all unnecessary function from State interface Why? Can we create a sperate interfaces?

[@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. 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

[@faizulhaq4527]

@Concept && Coding is it not violating the SOLID principle, as some of the classes does not have implementation of abstract methods

[@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.

[@faizulhaq4527]

@@ConceptandCoding thanks

[@soumyaripan5131]

Thank you!

[@nikhildalvi6896]

Great Video!! 1 question though, can we have the base class as abstract and all the functions in the base class would by default throw Exception, and the child classes would provide implementation for only specific methods they implement. Thinking this w.r.t. avoid duplicate code in all the child classes.

[@ConceptandCoding]

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

[@shubhamprasad2430]

@ConceptandCoding doesn't it violate the interface segregation principle? As we are having a big interface and all of the state concrete classes do not need to implement all of the methods

[@ConceptandCoding]

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

[@namansaraswat9691]

I have one question that here in this solution we have one state interface that is breaking Interface Segregation principal. Is this demerit of this design pattern or it can be modified?

[@ConceptandCoding]

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

[@samcooper-02]

@@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.

[@theUneditedNature]

@@samcooper-02 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 !

[@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. 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.

[@namansaraswat9691]

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

[@neelanshgulati2643]

According to interface segregation principle, should we have more fine grained interfaces rather than throwing exceptions from state classes?

[@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. 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.

[@neelanshgulati2643]

@@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.

[@mission_India_2025]

@@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.

[@deepak655655]

Is it adhering to "I" of the SOLID principles, as there are many non required interface methods in the concrete classes?

[@ConceptandCoding]

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

[@deepak655655]

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

[@hiteshbitscs]

One mistake you made I feel Vending machine has array of shelf and shelf has inventory. You mentioned vending machine has inventory and inventory has shelf.

[@sabinshrestha9496]

Hello sir, I want to be member in your youtube channel to see and learn some paid video, but I don't see option to be member in your channel. Does it matter from which country we are ?

[@ConceptandCoding]

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

[@jatinthakwani5370]

Great content!

[@ConceptandCoding]

Thank you

[@Sushil2874]

Awesome explanation !! BTW, which device are you using for writing in OneNote?

[@ConceptandCoding]

wacom tablet

[@sameerpattanaik9097]

the interface state you created, isn't it breaking the interface segmentation principle of SOLID ?

[@ConceptandCoding]

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

[@rajnishsingh6719]

pls make some video on java microservices if possible

[@ConceptandCoding]

sure

[@AmanKumar-dq4mz]

I think the very first question will be Scalability, suppose they ask for scaling payment process to accepting UPI / Card along with Cash. 2. Adding display, May be re-arranging the processes will solve some problems, but again few extra feature will lead to design failure. Let me know if I’m thinking in wrong direction.

[@ConceptandCoding]

Good thoughts process Aman. keep it up buddy

[@prashantgupta6160]

@shrayansh, how will be solving the payment scalability issue then?

[@ashutoshraturi8574]

@@prashantgupta6160 create an interface with PaymentStrategy, and then extend different types of payment strats such as CreditCardStrat or CashStrat etc.

[@zishanshaikh9375]

hasMoney state should not allow to insert another coin right ? as the coin is already entered in the idle state, correct me if i'm wrong

[@ConceptandCoding]

yes we can restrict that in our design.

[@khimanidhaval1964]

Why are you forcing the concrete state class to implement a state interface all method or throw an exception? We can use the Interface segregation principle here.

[@ConceptandCoding]

@@khimanidhaval1964 right we can change the interface to abstract class and provide the default implementation there

[@ehtashammazhar3518]

Hi , your video is really helpful. Could you please make a video about Inventory management System . this was asked in amazon interview.

[@ConceptandCoding]

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

[@PankajGupta-gh9cm]

i have one doubt In the solid principle video we have that Interface Segregation Principle in that we have to segregate interface such that it only implements interface of its need and we remove the extra not needed function . so i think State Design Pattern is not following that Principle beacause here Idle State and other States implementing all functions which are not required .in those functions they are just throwing Exception

[@ConceptandCoding]

Hi Pankaj, the same doubt i have cleared in the Live session kzbin.info/www/bejne/Y4bNm5mwf5pqatk Pls have a look, your doubt will get cleared

[@jeethanmontheiro7996]

what is difference between chain of responsibility and state design pattern?

[@ConceptandCoding]

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

[@NeerajSharma-mz4es]

Nice Video

[@viralipurbey6358]

Thanks for sharing. But how are we following the interface segregation principle here while using state design pattern?

[@aniketsharma5221]

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

[@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. 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