16. Design Vending Machine | LLD of Vending Machine | State Design Pattern | LLD interview question
Вставка
- Опубліковано 18 сер 2022
- - Code (GitLab) Link:
Shared in the Member Community Post (If you are Member of this channel, then pls check the Member community post, i have shared the Git link there)
- Become a Member: / @conceptandcoding
- Join telegram group: t.me/+KwJhmit5yDczNzY1
- LLD playlist:
if you like this LLD video, you might also like the series
• 1. SOLID Principles wi...
#vendingmachine #systemdesign #lld
This is by far one of the best and very easy to understand lld video I have seen.
Thank you Shrayansh.
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.
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.
nicely explained, got to know about State Design Pattern. Please keep uploading such LLD Questions for more understanding
Thanks
Thanks for all the lld videos. Hope you will add more videos to your ongoing LLD Playlist.
Yes, its in WIP, currently i am adding couple of HLD videos thwn will switch back to LLD
Really nice video and your explanation is better than others many one.
Thank you
Wow! very informative and detailed LLD video..keep going! 👏👏👏
thank you
Very beautifully and conceptually explained.
Thanks a lot 😊
Really well explained. Thanks a lot
thank you
Great explanation. Thank you.
Thanks 🙏
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).
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?
Thank you so much . This helps 🎉
Thanks a lot for detailed explanation
Glad it was helpful!
Thank you!
Great Explaination. Thanks
thanks
@conceptandcoding thanks for the video!
I am trying to understand if it would be better to keep 2 variables for selectedItem and insertedCoins in a VendingMachine class and change the variables based on what action the user takes? By using the state design pattern, we may not be able to do something like select an item first, and then pay. What is your opinion?
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!
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.
I am impressed 😄😅
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.
Thank you
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?
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.
Great Content
thank you
Ye badhiya tha Guru 😍
:) thanks
Great content, maza aagya..
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.
Nycly explained
thanks
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.
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
Great content!
Thank you
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.
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.
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?
Hi, could you pls check this live session which i took
ua-cam.com/video/-UjjfzJ574w/v-deo.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.
Thanku Bhaiyaji ...such a wonderful content as always , can we make another class for fillUpInventory and displayInventory methods to follow Solid Principle?
Ack, i will reply tomorrow.
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 ?
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.
Really Good
thanks Sachin
In Vending Machine Code which is present in github. there in Inventory class we have array of ItemShelves while initlaising those shelves why we are setting is isSoldOut to true ?
Hey, one question why are taking money before placing order, doesnt this adds more complexity? we should select product then collect money
Hi just one doubt throwing exception from state classes will voilate the Liskov Substitution Principle right.
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..
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.
very well explained brother, would like to have your take on elevator system.
I have already covered, pls check the complete playlist buddy
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
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
then on design the elevator also we can apply state design pattern?
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!
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.
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?
Yes we can take abstract class instead.
Awesome explanation !!
BTW, which device are you using for writing in OneNote?
wacom tablet
Great content 😀..Can you also share some resources for lld in c++ also
LLD in C++ does not matter Ayush. If you understand the object relationship and UML diagram, you can code in any language
Returning the change to user can have follow up question in form of famous coding question-> Coin change
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 😛
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
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.
Right, same i did in ATM design.
You are right buddy
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?
yes we can, and its much better than interface
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.
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.
Great Explanation, easy to understand for any one ....
One Question
Is this State design pattern is not violating the SOLID principle [Interface segmented principle] ??
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 👌
How to design system which needs data storage without using any data base(both in memory and physical). Like gym membership , payment processing system (onboarding merchants etc.)
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.
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.
Hi , your video is really helpful. Could you please make a video about Inventory management System . this was asked in amazon interview.
Noted. Let me add it in my todo list, thanks for sharing.
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 :)
thanks Mustafa for input
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.
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
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.
User is not calling the dispense product method, it is a chained method call from the selection state
@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).
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
❤️
I have when we are writing the state interface and writing concrete classes for that and throwing exception if does not support but as per SOLID "L" says it should be replaceable with the either of sub classes which is violated right? cant we do writing different interface for all and remove that thing.
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.
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.
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
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?
you can also design vending machine using chain of responsibility, do try it out.
there are many ways to design one system.
Hey,
Shouldn't we have used composition here, we are implementing methods not required for Idle State, just because it implements State?
@ConceptAndCoding
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.
right, in comment section i have mentioned this to avoid duplication
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?
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.
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?
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
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
yes we can restrict that in our design.
Is it adhering to "I" of the SOLID principles, as there are many non required interface methods in the concrete classes?
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?
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?
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
Can we use chain of responsibility design pattern here, as we can specify next state as well using it?
Can you provide the UML git link or elaborate more information, how you will gonna proceed with this design patterns Neelansh
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
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
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
Hi Pankaj, the same doubt i have cleared in the Live session ua-cam.com/video/-UjjfzJ574w/v-deo.html
Pls have a look, your doubt will get cleared
doesnt this break liskov substitution principle?thanks for great videos!
Could you please elaborate how?
@@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
Thanks for sharing. But how are we following the interface segregation principle here while using state design pattern?
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
According to interface segregation principle, should we have more fine grained interfaces rather than throwing exceptions from state classes?
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.
Won’t there be problem of circular dependency?
I think in state design we are not following the interface segmentation as we said in SOILD right?
could you please elaborate why? we can discuss
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?
We can have abstract class instead of interface
@@ConceptandCoding even then in concrete class we should throw exception only no
@@shriharikulkarni3986 in parent class itself we can throw exception, and which ever child want to override the behaviour they can override that method
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?
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
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?
Maybe we can just have a handle function in the State Interface. And accordingly the other states should be implemented.
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 ?
we can change the interface to abstract class and provide the default implementation there. so that child classes should not unnecessarily throw exception.
Will we need to have ipad or something. As , interview could be happening online and i dont think its comfortable with mouse to draw shapes and characters
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
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
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)
@Concept && Coding is it not violating the SOLID principle, as some of the classes does not have implementation of abstract methods
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 thanks
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??
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!
Hi
in hasMoney state, we can only insert cash isn't?
only after inserting cash, we can either press select product or cancel to get the refund.
can this be done in two different states rather than one?
please share your thoughts on this
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.
pls make some video on java microservices if possible
sure
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 ?
It's a youtube option, generally at home page you should be able to see Join button
in dispense state, calling a method inside the constructor seems like an anti-pattern
Umm any other solution can you provide, and why you think it's anti pattern
@@ConceptandCoding anit pattern in the sense that, main job of a constructor should be to create intialise an instance, and not call an instance method, for that instance should be used, solution i should propose is the same - use the instance.
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.
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?
@@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. :)
what if a the machine can be present in two or more states? How will we handle that?
Can you please tell me the usecase of two states of machine at the same time?
I am a member of the channel. How to access the code link to the GitLab?
pls check the member community section buddy
what is difference between chain of responsibility and state design pattern?
Pls check the Design ATM video, i have covered it in that i have used both, it will clarify your doubt
now adding a new item we have to modify the existing class which violates o in solid
Could you please elaborate
the interface state you created, isn't it breaking the interface segmentation principle of SOLID ?
we can change the interface to Abstract class and implement a method there so that all child classes will not override the method.
Hey doesn't the IdleState violates Interface segregation principle ? no code should be forced to depend on methods it does not use
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.
Is there any other way to implement this desgin without having to leave blank implementations of other state thats not needed?
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 ?
Wasnt Vending machine a Chain of responsibilty design pattern?
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.
Good thoughts process Aman. keep it up buddy
@shrayansh, how will be solving the payment scalability issue then?
@@prashantgupta6160 create an interface with PaymentStrategy, and then extend different types of payment strats such as CreditCardStrat or CashStrat etc.
Can we apply state design pattern on Elevator LLD also?
could you please elaborate your strategy for it. and try it out once