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

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

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

@ConceptandCoding

11 ай бұрын

Thanks

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

@ConceptandCoding

Жыл бұрын

thank you

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.

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

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

@ConceptandCoding

Жыл бұрын

Thank you

Very beautifully and conceptually explained.

@ConceptandCoding

9 ай бұрын

Thanks a lot 😊

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

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 ?

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.

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

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

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.

Really well explained. Thanks a lot

@ConceptandCoding

Жыл бұрын

thank you

then on design the elevator also we can apply state design pattern?

Great explanation. Thank you.

@ConceptandCoding

Жыл бұрын

Thanks 🙏

Thanks a lot for detailed explanation

@ConceptandCoding

Жыл бұрын

Glad it was helpful!

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

Great Explaination. Thanks

@ConceptandCoding

6 ай бұрын

thanks

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.

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?

Ye badhiya tha Guru 😍

@ConceptandCoding

Жыл бұрын

:) thanks

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

11 ай бұрын

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

6 ай бұрын

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

@bhaveshshah3405

6 ай бұрын

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.

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

Thank you so much . This helps 🎉

Hey, Shouldn't we have used composition here, we are implementing methods not required for Idle State, just because it implements State? @ConceptAndCoding

Won’t there be problem of circular dependency?

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.

@ConceptandCoding

6 ай бұрын

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.

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

2 ай бұрын

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

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

7 күн бұрын

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

Best so far

@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

2 ай бұрын

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

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

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.

I am not getting github link , can you please share

Nycly explained

@ConceptandCoding

Жыл бұрын

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.

@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

Great Content

@ConceptandCoding

Жыл бұрын

thank you

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.

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

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.

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

I am impressed 😄😅

Great content!

@ConceptandCoding

Жыл бұрын

Thank you

Really Good

@ConceptandCoding

Жыл бұрын

thanks Sachin

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 kzread.info/dash/bejne/X4mezMizepidZNo.html 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.

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

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

2 ай бұрын

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

But I think in this, I principle is not followed Interface segmented principle.Child class are not implementing all the functions mentioned in the Interface.

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

6 ай бұрын

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.

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

how we can refund 18 rs if coin was nickel and quarter? you are restting the coin list when moving the machine to idle

Hi Shrayansh, Can you please help me with an answer? I think the State Design Pattern violates InterfaceSegregationPrinciple. Any reason why we still use it? Maybe I am wrong. Can you please help me pointing out the difference?

@ConceptandCoding

24 күн бұрын

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

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

6 ай бұрын

yes we can restrict that in our design.

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

4 ай бұрын

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.

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

2 ай бұрын

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

Nice Video

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

@ConceptandCoding

Жыл бұрын

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

@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

24 күн бұрын

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

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

@ConceptandCoding

2 ай бұрын

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

@deepak655655

2 ай бұрын

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

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

11 ай бұрын

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

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.

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

@ConceptandCoding

5 ай бұрын

could you please elaborate why? we can discuss

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

@sakshamsrivastava6280

19 сағат бұрын

@ConceptandCoding

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

@ConceptandCoding

Жыл бұрын

I have already covered, pls check the complete playlist buddy

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

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

10 ай бұрын

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

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

8 ай бұрын

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

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 👌

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

Can we use chain of responsibility design pattern here, as we can specify next state as well using it?

@ConceptandCoding

Жыл бұрын

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

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

2 ай бұрын

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

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

9 ай бұрын

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

Wasnt Vending machine a Chain of responsibilty design pattern?

anyone facing cyclic dependancy issue as state imports vending machine and vending machine imports state interface. Was trying to replicate the logic in cpp facing this issue. Any help will be appreciated :).

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.

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

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

@ConceptandCoding

Жыл бұрын

wacom tablet

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

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 kzread.info/dash/bejne/X4mezMizepidZNo.html Pls have a look, your doubt will get cleared

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

6 ай бұрын

yes we can, and its much better than interface

what if a the machine can be present in two or more states? How will we handle that?

@ConceptandCoding

Жыл бұрын

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

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

15 күн бұрын

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

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

2 ай бұрын

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?

@ConceptandCoding

11 ай бұрын

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

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

6 ай бұрын

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.

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

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

@ConceptandCoding

Жыл бұрын

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

@priyadarshinir9730

Жыл бұрын

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

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

guys i am not able to find the gitLab link , where i can find it?

@ConceptandCoding

3 ай бұрын

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

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.

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

@parissweetheart96

Жыл бұрын

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

Жыл бұрын

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

@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

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

@ConceptandCoding

4 ай бұрын

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

@ConceptandCoding

Ай бұрын

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

@neelaadityakumar

Ай бұрын

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

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

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

2 ай бұрын

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

2 ай бұрын

@@ConceptandCoding Got it, thanks!

Is there any other way to implement this desgin without having to leave blank implementations of other state thats not needed?

@ConceptandCoding

Ай бұрын

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

@ayushisingh6638

Ай бұрын

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