Even though the explanation is not the best, you need to know SOLID principles and the reason we need it. After that you should attempt these design pattern.
I think it's clear, but what if you want to get a ConcreteRestaurant based on a kind of selector? In the main method, u still will have to do some sort of check to retrieve the proper ConcreteRestaurant. To add a new ConcreteRestaurant to the main method, u still will have to modify that and that breaks the open/closed principle.
I think the issue here is with having to change the code every time a variation of an object is to be added or taken out, the problem is not with knowing which kind of object you need to create.so simply put you do know what object you're about to create and there is no need to worry about the check to be performed in the main method, but you do have to worry about the different variations of the object that might change in the future. Not sure if I'm right or not but that's my humble understanding
@@hossemhrichi6570 My question was a long time ago, but I think the answer lies in the "Open/closed". In theory, adding additional checks for a factory idiom doesn't necessarily break the open/closed principle. We are extending the code, not modifying the existing code. We don't change the behaviour or rewrite a functions. We just extend the code by adding a new case to the factory. I think that is safe.
Best video, that explains Factory Method Pattern until now I am always looking for this type of videos that explain advanced topics with a short and interactive presentation and with concrete examples. Many thanks
I dont understand the exemple, at 5:57 how the client know wich one to get, and why not just give the object directly without passing it trough the factory ? what is the difference now ?
By abstracting the creation logic and applying the factory pattern we centralized the product creation in one place making it very easy to extend our application with new products, all-while making sure that the creation-template (ex: order - create then prepare) will be preserved.
I had the same question. It seems like the ability to order a burger subclass based on user input has been lost. At 5:57 we are just making both kinds of burger
@@yuzheng8804 I thing the if else logic will be moved to the main class so you will need to check the request to see which burger customers want to order then call the method in abstract class to create the burger base on the type
Great video! I have a simple question: before implementing the factory, you had a string called request used on the if else block. after implementing the factory, at 5:55, you showed a main function but instantiated two objetcs without using the string request as before. if i wanted to adapt the first code (with the if else based on the request string) the right place to put the if else block with the request string would be in the main, right?
Thanks :) Yes! This is a client request and should be handled on the client part of the code (i.e. in this simple example the main class). We can't get rid of the request entirely, is part of how any program or application works. What we did instead was extract it, so it won't be coupled with our logic, making our inner logic closed for modification but open for extension. Hope this helps!
I don't know how this achieves anything... the outer (ordering) code is still coupled to the inner (making) code because it still has to know the names of the functions it can call. Also, if you wanted to replace veggie with chicken, as you did in the first example, then you would still have to update the outer code so it can't call the deleted veggie burger type. So what's the point?
If the whole point of applying this pattern was to make the logic close to modification then i think it didn't succeed. The conditional didn't disappear we just pushed it a level higher. So that is still open to modification. Also, we created an extra level of classes with this pattern (XYBurger -> XYBurgerRestaurant + XYBurger), so now we have to write code for twice as many classes every time we want to add a new kind of Burger.
Your example is good, I would suggest, that you call Creator as BurgerFactory instead of Restaurant, the method in the factory is createBurger, concrete class will be BeefBurger and Veggie Burger; so the Restaurant will be the client of your BurgerFactory, a similar way this restaurant can have another factory let say FriedriceFactory. It shows as if you are creating new restaurants otherwise
Forgive my dumb question, I'm not sure if this is just the example chosen, but... In the first part, by closing the restaurant class, the factory pattern opens a new burger factory class, which pretty much does the same thing, only with more code... This isn't a full factory pattern. So, the solution is instead, to create _two restaurant_ subclasses, one restaurant for each burger type instead??? Of course, the primary use case is when you don't know how many products there will be, which is why you want to separate the concerns. But I don't get how a customer knows whether to "visit" a BeefBurgerRestaurant or a VeggieBurgerRestaurant. Eventually an if-else will need to be placed somewhere, right?
There are no dumb questions my friend :) Yes, but now that "if-else" is on the client side and not tightly coupled with our code. We separated concerns and shifted the decision making to the client side.
Hello sir, Nicely explained 👌 But I have a doubt. In the factory pattern method, in the main() method still I have to apply if else on which type of derived class I have to instantiate. I will give the type in input and on that input if-else would have to applied for making instances of the derived classes of the Restaurant class. So, in this case also, suppose if a new burger comes in, I have to increase one "if" check. How to handle this?
Thanks :) We cannot get rid of that decision entirely as it is up to the user / client to make this selection, or else we will be choosing on his / her behalf :P What we can do, or are doing instead is shift this decision to the client part of our application instead of leaving it coupled with the inner parts of our algorithm :) Hope this answers it! Cheers!
@@geekific But I still have a doubt. Before "Simple factory idiom": if-else checks were in the Restaurant class. To remove those checks from the Restaurant class, we used "Simple factory idiom" which led to those checks in FactoryClass. Then to remove if-else checks from the factory class, we used "Factory class pattern" which led to the checks in the main method. So, I am not able to undertake what benefit we are getting by using the Factory pattern over Simple factory idiom. We are back with those checks in our client code!!!!.
@@rahulmodi926 to remove if-else (control-coupoling problem), i think you can do it with reflection, so you have to create object from its className, so ur className have to name after a rule like: type+...(ex: type: beef -> className: Beff + Burger, type: vergie -> className: Vergie + Burger), so in future, if u have a new product, you have to name after the rule. In conclusion: if-else in that case is not important, if u want to remove it -> use reflection and className should follow a specific rule
With the abstraction of the restaurant and have that createBurger abstract method, it looked like a Method Template Design Pattern. There are so many similarities in design patterns
Hello! This video has been helpful! I do wonder if it is better to make createBurger method protected instead of public since the main method can access it and be able to create a burger without ordering it?
Thank you :) More than one pattern can be used to tackle any given situation, in our videos we are trying to explore the best pattern to use given a certain situation or approach!
well, make a BurgerRegistry, register your burgers associated to a name. Give this registry to the Restaurant class. When a request comes, ask your registry to get the burger you want ! You just will have to register all your burgers as concrete implementations in a registry accepting all kinds of Burger instance... Now, my restaurant can deliver all kinds of existing burgers...
It seems that by getting rid of the simpleBurgerFactory class we are getting rid of the ability to generate any (i.e. unknown at compile time) type of burger at run time.. (i.e we no longer can simulate a random costumer order)
@@geekific so if i understand correctly, the aim here was to decouple the "if,else,else" request logic from our actual object creation logic? I.e. this closes our new object creation logic for modification.
Ok, now client (main method) is not dependent on burgers, but it is dependent different kind of restaurants now😅 In the main class we still create concrete factory class objects. I couldn't understand the benefit
Yeah, I was also wondering why one restaurant was split into 2 different restaurants just to solve the issue with orders. There must be a better example to explain this case
If we have a method createBurger in controller class in a web app and we need to create a burger we have to again put if else conditions to create different types of burger. Then what is the point to use this design pattern?
Thanks! It is actually a better practice to use "string".equals(request) as if the request passed to the equals method is null it will return false, however this one request.equals("string") will throw a NullPointerException! Cheers!
While the concepts were explained well, i think there could be better examples that demonstrates this design pattern. In reality, restaurants will have different menu instead of solely having beef burger only or veggie burger only restaurant. I do understand though that it was created for the mere purpose of resolving the OCP for the if else statement, although this could result in class explosion if there will be lots of items to be generated by the factory. Great content otherwise. Subscribed to the channel
Hey, u said that we are no more dependent on request, but how? Imagine we get even a console application and need to get a single line request for the input, so we anyway need to check it either with equals or enum type idk. If i misunderstood your ider, plrase can u answer my question
As long as it is on the client side you are fine. For example if you had a UI where you click on stuff that forwards you to the needed object, you won't even need the conditional if's because that UI construct will immediately make use of the appropriate logic! We will be uploading a video on how to make use of these patterns, so Stay Tuned!
Why can’t you create a generic burger class and pass a burger type param while calling the method .createBurger and returns based on that param, creating a class for each type is something I don’t think its practical
For very small and trivial examples it may work, but what if you had large functionalities that vary for each sub-product? Your code will be coupled and you will have one generic class that handles several responsibilities. Cheers!
I newbie to lld What I understand from this video is.. WHEN TO USE: we can use it anywhere where we can create new objects without any modification THINGS TO NOTE: we have to divide the class till we can't find any further modification will occur. We make common methods as interfaces implemented classes will overide them. We are making loose coupling to make client to choose We must follow single responsibility principle Are there any i missed? Your videos are awesome glad to knew 🎉 new subcriber 😊I will stay tuned for upcoming ones.
Thanks for the feedback. Please let me know which parts where not clear so I can clarify in the comments, or how would you improve it so we can enhance our methodology in future videos :) Cheers!
@@geekific Everything is clear and understable. Just usage example is bad, I know it is for simplicity sake, but real project usecase would give more idea what do we gain by using this pattern
I don't think this video is good. Let me give you constructive feedback. The video should have been presented this way: 1. here is some code 2. it has shortcoming X 3. here is the same code with the Factory Method Pattern applied 4. now it no longer has shortcoming X You have not made clear in the video what was gained, and you did not end up with the same in-code if-else choice of burgers based on an input string. What we are looking to understand as viewers is: What does this solve? What does this get me that I didn't have before? Remember, the whole motivation for "open-closed" was to avoid recompiling modules that did not actually need changing with better architecture, hence to save time. So tell us in your narrative what is the module/class you are wanting to avoid having to recompile, and how in the end, with your solution, you can add new burgers without having to recompile said module/class. I hope this helps.
@@geekific No problem. After watching many other videos on this exact same topic - Factory Method Design Pattern - here on RUclips, I have come to find there is not a single video that explains it clearly from beginning to end with one example suffering from a shortcoming that is then remedied by this pattern - not one video. So do not beat yourself up about it, because your competition are not doing any better a job at this. I am actually having trouble finding a good example in all of the web. There needs to be one example showing how in the end, a user-input supplied as a string, gets translated into a choice of class, without that specific part of the translation needing change in order to add code. Because if that is not demonstrated, then you will still have people asking "but why not then simply do the choice and dispatch right there and then at the site where you are having to make this choice anyway?". You really have to demonstrate that you are saving me time by saving me from re-compiling other classes. In the end this is the only benefit of the Open-Closed principle - not introducing bugs accidentally is usually caught at pull-request review time and no longer an issue. Thank you for listening and I look forward to your next video. If you don't do it, I will, so good luck! ;)
@@jboss1073 I have on my list of upcoming videos kind of a follow-up on these patterns, where we will create a UI and allow you to see how conditionals are not needed/handled better due to the use of patterns :) Stay Tuned! I always appreciate such feedbacks, keep them coming!
@@geekific It is my pleasure to give feedback to someone who cares about improving like you do. Thank you for taking the effort to make these videos. I have subscribed and will stay tuned!
@@jboss1073 I am learning and based on this video tried to design keeping in mind what you are asking for. Could you please have a look and suggest - much appreciate your time. public abstract class BurgerFactory { public Burger makeBurger(String[] specs) { Burger burger = CreateBurger(); burger.PrepareBurger(specs); return burger; } public abstract Burger CreateBurger(); } // BurgerFactory public class ChickenBurgerFactory extends BurgerFactory { @Override public Burger CreateBurger() { return new ChickenBurger(); } } // Class public class BeefBurgerFactory extends BurgerFactory { @Override public Burger CreateBurger() { return new BeefBurger(); } } public interface Burger {
public void PrepareBurger(String[] specs); // Code to prepare Burger, cust spec } public class ChickenBurger implements Burger { @Override public void PrepareBurger(String[] specs) { System.out.println("You ordered Chicken Burger with: " + " "); System.out.println(Arrays.toString(specs));
} } // class public class BeefBurger implements Burger { @Override public void PrepareBurger(String[] specs) { System.out.println("You ordered Beef Burger with: "); System.out.println(Arrays.toString(specs)); } } public class Demo { private static BurgerFactory myBurger; private static Burger burger; private static String[] attribs;
public static void main(String[] args){ attribs = new String[] {"Pineapple", "Thin Crust", "Onion", "Mushroom"}; String request = "BeefBurger"; //"ChickenBurger" => could be anything or // combination; OrderMenu(request, attribs); eatMenu();
} // main
} // Demo 1. Dropping item from Menu - code will work fine 2. For OCP - With new menu item (xxburger) another factory (VeggieBurgerFactory) and VeggieBerger need to be added and Demo/Front end need to be modified. 3. Also if we want to limit endless creation of factories, do you think method overriding PrepareBurger might help ? Thanks much for your time.
I usually use an interface instead of an abstract class. An Interface means that I am creating a "contract" for all Restaurants and it´s mandatory that all the classes implementing it will implement the createBurguer. An abstract class should be used for generalization of a behaviour, an interface for standardization, this case looks like standardization to me. Meaning: Generalizing: "All these classes seem to work this way, lets sum up common code in a common place" Standardizing: "I want to enforce that all this classes behave this way" What do you think about this approach and why would you favour the use of an abstract class over an interface?
I guess, interfaces enforce a contract, ensuring all implementing classes follow the same methods, making them ideal for standardizing behavior. Abstract classes, however, offer shared code, making them better for generalization when multiple classes need common functionality. They allow partial implementations and can be more flexible when evolving over time. So, imo choose interfaces when you need consistency across classes and abstract classes when you want to combine shared logic with enforced structure. Does this answer your question?
I don't understand everything... but one thing i do understand is food. Great videos!
Yeah that's why I never liked food analogies.
Even though the explanation is not the best, you need to know SOLID principles and the reason we need it. After that you should attempt these design pattern.
@@abhilashpatel6852 Exactly I am going through this second time after finishing clean architecture book and it hits different now.
This is by far the clearest and the most well constructed explanation of the factory method design pattern
Glad it was helpful!
I think it's clear, but what if you want to get a ConcreteRestaurant based on a kind of selector? In the main method, u still will have to do some sort of check to retrieve the proper ConcreteRestaurant. To add a new ConcreteRestaurant to the main method, u still will have to modify that and that breaks the open/closed principle.
I have the exact same doubt. Can anyone answer this?
I was looking exactly for this comment. Any answers?
@@nagagouthamnarne790 I think this explanation has some misinformations ...
I think the issue here is with having to change the code every time a variation of an object is to be added or taken out, the problem is not with knowing which kind of object you need to create.so simply put you do know what object you're about to create and there is no need to worry about the check to be performed in the main method, but you do have to worry about the different variations of the object that might change in the future.
Not sure if I'm right or not but that's my humble understanding
@@hossemhrichi6570 My question was a long time ago, but I think the answer lies in the "Open/closed". In theory, adding additional checks for a factory idiom doesn't necessarily break the open/closed principle. We are extending the code, not modifying the existing code. We don't change the behaviour or rewrite a functions. We just extend the code by adding a new case to the factory. I think that is safe.
Super super helpful explanation, the code separated in boxes makes it more manageable to understand, thanks a lot! I'm totally subscribing
Man this channel is teaching me everything on Design Patterns man! Thank you so much
Glad I could help!! Keep it up man!
He deserves to have one million subscribers.
I am understanding these design pattern videos so well . Thank you very much . We need teachers like you sir :)
i wish i can express how helpful your videos are
You already did! :)
Good example of Factory Method design pattern and It will help viewers to understand the need of abstract factory now.. Thanks for sharing knowledge 🤝
Thanks for your comment! Glad you liked it :)
i have been watching your design patterns series for a couple of days and those videos are great!!! thanks and keep going
Thank you, it was really easy to understand, and your method of explanation is probably one of the best!
Wonderful job. Cheers from Perú!!
Unbelievable that such a great pattern explanation like this exists
Thank you for the help. The restaurant idiom and UML diagrams are helping me understand this design pattern better so I can complete my assignment.
Glad it was helpful! Good luck with the assignment :)
Best video, that explains Factory Method Pattern until now
I am always looking for this type of videos that explain advanced topics with a short and interactive presentation and with concrete examples.
Many thanks
Great video!
Great explanation, to the point, clear and concise.
Thank you so much for this progressive explanation of the Factory Method Pattern
Nice Video and nice Reverb!
Very clear explanation. Thanks, a lot.
I dont understand the exemple, at 5:57 how the client know wich one to get, and why not just give the object directly without passing it trough the factory ? what is the difference now ?
By abstracting the creation logic and applying the factory pattern we centralized the product creation in one place making it very easy to extend our application with new products, all-while making sure that the creation-template (ex: order - create then prepare) will be preserved.
I had the same question. It seems like the ability to order a burger subclass based on user input has been lost. At 5:57 we are just making both kinds of burger
I got same problem lol
@@geekific Nice video. Just one question, how can we runtime decide which burger to be created? Thanks.
@@yuzheng8804 I thing the if else logic will be moved to the main class so you will need to check the request to see which burger customers want to order then call the method in abstract class to create the burger base on the type
You are great Dude! Happy I found your channel
Superduper . Thanks a lot.
super simple explanation
Well explained, thanks!
Great video my friend, everything is explained so clearly.
You should deserve more subscribers and views. Nice explanation!
what a great explanation
thanks god we have you mate
Great video!!! Thank you
Крутейшая связка, редко такой процент бывает
okay, now I know what OOP persons mean with factories.
Now I can go back to assembly and be happy.
Really good explanation!
fantastic video to understand design patterns but kindly provide the code in the description
You can find all our code snippets in our GitHub repo!
Great video!
I have a simple question: before implementing the factory, you had a string called request used on the if else block. after implementing the factory, at 5:55, you showed a main function but instantiated two objetcs without using the string request as before. if i wanted to adapt the first code (with the if else based on the request string) the right place to put the if else block with the request string would be in the main, right?
Thanks :) Yes! This is a client request and should be handled on the client part of the code (i.e. in this simple example the main class). We can't get rid of the request entirely, is part of how any program or application works. What we did instead was extract it, so it won't be coupled with our logic, making our inner logic closed for modification but open for extension. Hope this helps!
I don't know how this achieves anything... the outer (ordering) code is still coupled to the inner (making) code because it still has to know the names of the functions it can call. Also, if you wanted to replace veggie with chicken, as you did in the first example, then you would still have to update the outer code so it can't call the deleted veggie burger type. So what's the point?
@@richtourist this is my question exactly I just dont get it!!
If the whole point of applying this pattern was to make the logic close to modification then i think it didn't succeed. The conditional didn't disappear we just pushed it a level higher. So that is still open to modification. Also, we created an extra level of classes with this pattern (XYBurger -> XYBurgerRestaurant + XYBurger), so now we have to write code for twice as many classes every time we want to add a new kind of Burger.
Legend, thank you!
Your example is good, I would suggest, that you call Creator as BurgerFactory instead of Restaurant, the method in the factory is createBurger, concrete class will be BeefBurger and Veggie Burger; so the Restaurant will be the client of your BurgerFactory, a similar way this restaurant can have another factory let say FriedriceFactory. It shows as if you are creating new restaurants otherwise
Thanks for the feedback, will try to keep this in mind for future videos :)
Forgive my dumb question, I'm not sure if this is just the example chosen, but... In the first part, by closing the restaurant class, the factory pattern opens a new burger factory class, which pretty much does the same thing, only with more code... This isn't a full factory pattern. So, the solution is instead, to create _two restaurant_ subclasses, one restaurant for each burger type instead??? Of course, the primary use case is when you don't know how many products there will be, which is why you want to separate the concerns. But I don't get how a customer knows whether to "visit" a BeefBurgerRestaurant or a VeggieBurgerRestaurant. Eventually an if-else will need to be placed somewhere, right?
There are no dumb questions my friend :) Yes, but now that "if-else" is on the client side and not tightly coupled with our code. We separated concerns and shifted the decision making to the client side.
@@geekific Thank you for the clarification!
@geekific Thank you. As a student this is incredibly helpful!
Nice question, bro 🎉
Nice question, bro 🎉
Hello sir, Nicely explained 👌
But I have a doubt. In the factory pattern method, in the main() method still I have to apply if else on which type of derived class I have to instantiate. I will give the type in input and on that input if-else would have to applied for making instances of the derived classes of the Restaurant class. So, in this case also, suppose if a new burger comes in, I have to increase one "if" check. How to handle this?
Thanks :) We cannot get rid of that decision entirely as it is up to the user / client to make this selection, or else we will be choosing on his / her behalf :P What we can do, or are doing instead is shift this decision to the client part of our application instead of leaving it coupled with the inner parts of our algorithm :) Hope this answers it! Cheers!
@@geekific But I still have a doubt. Before "Simple factory idiom": if-else checks were in the Restaurant class. To remove those checks from the Restaurant class, we used "Simple factory idiom" which led to those checks in FactoryClass. Then to remove if-else checks from the factory class, we used "Factory class pattern" which led to the checks in the main method. So, I am not able to undertake what benefit we are getting by using the Factory pattern over Simple factory idiom. We are back with those checks in our client code!!!!.
@@rahulmodi926 to remove if-else (control-coupoling problem), i think you can do it with reflection, so you have to create object from its className, so ur className have to name after a rule like: type+...(ex: type: beef -> className: Beff + Burger, type: vergie -> className: Vergie + Burger), so in future, if u have a new product, you have to name after the rule. In conclusion: if-else in that case is not important, if u want to remove it -> use reflection and className should follow a specific rule
@@sopecoto I think you can use a map of [burger_type: object()]
With the abstraction of the restaurant and have that createBurger abstract method, it looked like a Method Template Design Pattern. There are so many similarities in design patterns
Yes there are!
maybe their structures are identical, but their purposes are different. one is for creation another is for computation. I am not sure.
What if my restaurants wants to serve both types of burgers. You changed the problem statement in the second design pattern.
yes exactly!
Hello! This video has been helpful! I do wonder if it is better to make createBurger method protected instead of public since the main method can access it and be able to create a burger without ordering it?
well done. Nicely explained.
Glad it was helpful!
Great work as usual. But I have a question could we use state pattern in this situation?
Thank you :) More than one pattern can be used to tackle any given situation, in our videos we are trying to explore the best pattern to use given a certain situation or approach!
Perfect!
i really liked that you removed the veggie burger from the menu 👍
well, make a BurgerRegistry, register your burgers associated to a name. Give this registry to the Restaurant class.
When a request comes, ask your registry to get the burger you want !
You just will have to register all your burgers as concrete implementations in a registry accepting all kinds of Burger instance...
Now, my restaurant can deliver all kinds of existing burgers...
It seems that by getting rid of the simpleBurgerFactory class we are getting rid of the ability to generate any (i.e. unknown at compile time) type of burger at run time.. (i.e we no longer can simulate a random costumer order)
Even if you don't have a class for it, but you will still need to add it to the if-else ladder you have, hence it is in some way "known".
@@geekific so if i understand correctly, the aim here was to decouple the "if,else,else" request logic from our actual object creation logic? I.e. this closes our new object creation logic for modification.
Ok, now client (main method) is not dependent on burgers, but it is dependent different kind of restaurants now😅 In the main class we still create concrete factory class objects. I couldn't understand the benefit
What if you dont know the exact factory type at compile time?
May I have these ppt for presentation in university😊😋
To solve Single responsibility and Open-Closed principles, you need to split the restaurant ? 🤔
That's a really confusing example to be honest.
Sorry to read that! Let me know which parts were confusing so we can try to help :)
Yeah, I was also wondering why one restaurant was split into 2 different restaurants just to solve the issue with orders. There must be a better example to explain this case
If we have a method createBurger in controller class in a web app and we need to create a burger we have to again put if else conditions to create different types of burger. Then what is the point to use this design pattern?
You'll need a UX designer ;)
I do not know what to say except thank you.
You are most welcome :)
Great video, but the "string".equals(request) part is kind of bothering me LOL. I prefer request.equals("string") instead. Is it just me?
Thanks! It is actually a better practice to use "string".equals(request) as if the request passed to the equals method is null it will return false, however this one request.equals("string") will throw a NullPointerException! Cheers!
While the concepts were explained well, i think there could be better examples that demonstrates this design pattern. In reality, restaurants will have different menu instead of solely having beef burger only or veggie burger only restaurant. I do understand though that it was created for the mere purpose of resolving the OCP for the if else statement, although this could result in class explosion if there will be lots of items to be generated by the factory. Great content otherwise. Subscribed to the channel
For each berger we have a restaurant?
It doesn't make sense
@@payamzahedi7765 Yeah but it is the example provided
Hey, u said that we are no more dependent on request, but how? Imagine we get even a console application and need to get a single line request for the input, so we anyway need to check it either with equals or enum type idk. If i misunderstood your ider, plrase can u answer my question
As long as it is on the client side you are fine. For example if you had a UI where you click on stuff that forwards you to the needed object, you won't even need the conditional if's because that UI construct will immediately make use of the appropriate logic! We will be uploading a video on how to make use of these patterns, so Stay Tuned!
This video made me hungry
we also need a delivery pattern
I wish I could buy You a Burger 🍔 for Your Excellent Video 😀
Why can’t you create a generic burger class and pass a burger type param while calling the method .createBurger and returns based on that param, creating a class for each type is something I don’t think its practical
For very small and trivial examples it may work, but what if you had large functionalities that vary for each sub-product? Your code will be coupled and you will have one generic class that handles several responsibilities. Cheers!
When we want a beef burger , why are we creating a beef burger restaurant class?
Because in this example restaurants are the "factories" that produce burgers!
font?
which part?
@@geekific the font what ur using in intelij
www.jetbrains.com/lp/mono/
@@geekific thanks, also ur videos are very in-depth explained and clear to understand
Nice code of C#, skskskskkskskskssksk.
At the moment I am commenting, it has 55 views. In a year from now there will be 5 zeros after the number 55. :P
Thanks a lot for the support
I newbie to lld
What I understand from this video is..
WHEN TO USE:
we can use it anywhere where we can create new objects without any modification
THINGS TO NOTE:
we have to divide the class till we can't find any further modification will occur.
We make common methods as interfaces implemented classes will overide them.
We are making loose coupling to make client to choose
We must follow single responsibility principle
Are there any i missed?
Your videos are awesome glad to knew 🎉 new subcriber 😊I will stay tuned for upcoming ones.
Explained decent, but example in my opinion is poor. Based on example you see more complexity for basically no benefits.
Thanks for the feedback. Please let me know which parts where not clear so I can clarify in the comments, or how would you improve it so we can enhance our methodology in future videos :) Cheers!
@@geekific Everything is clear and understable. Just usage example is bad, I know it is for simplicity sake, but real project usecase would give more idea what do we gain by using this pattern
I don't think this video is good. Let me give you constructive feedback.
The video should have been presented this way:
1. here is some code
2. it has shortcoming X
3. here is the same code with the Factory Method Pattern applied
4. now it no longer has shortcoming X
You have not made clear in the video what was gained, and you did not end up with the same in-code if-else choice of burgers based on an input string.
What we are looking to understand as viewers is: What does this solve? What does this get me that I didn't have before?
Remember, the whole motivation for "open-closed" was to avoid recompiling modules that did not actually need changing with better architecture, hence to save time. So tell us in your narrative what is the module/class you are wanting to avoid having to recompile, and how in the end, with your solution, you can add new burgers without having to recompile said module/class.
I hope this helps.
Thanks for the feedback, will definitely take this into account for upcoming videos!
@@geekific No problem. After watching many other videos on this exact same topic - Factory Method Design Pattern - here on RUclips, I have come to find there is not a single video that explains it clearly from beginning to end with one example suffering from a shortcoming that is then remedied by this pattern - not one video. So do not beat yourself up about it, because your competition are not doing any better a job at this.
I am actually having trouble finding a good example in all of the web. There needs to be one example showing how in the end, a user-input supplied as a string, gets translated into a choice of class, without that specific part of the translation needing change in order to add code.
Because if that is not demonstrated, then you will still have people asking "but why not then simply do the choice and dispatch right there and then at the site where you are having to make this choice anyway?".
You really have to demonstrate that you are saving me time by saving me from re-compiling other classes. In the end this is the only benefit of the Open-Closed principle - not introducing bugs accidentally is usually caught at pull-request review time and no longer an issue.
Thank you for listening and I look forward to your next video. If you don't do it, I will, so good luck! ;)
@@jboss1073 I have on my list of upcoming videos kind of a follow-up on these patterns, where we will create a UI and allow you to see how conditionals are not needed/handled better due to the use of patterns :) Stay Tuned!
I always appreciate such feedbacks, keep them coming!
@@geekific It is my pleasure to give feedback to someone who cares about improving like you do. Thank you for taking the effort to make these videos. I have subscribed and will stay tuned!
@@jboss1073 I am learning and based on this video tried to design keeping in mind what you are asking for. Could you please have a look and suggest - much appreciate your time.
public abstract class BurgerFactory {
public Burger makeBurger(String[] specs) {
Burger burger = CreateBurger();
burger.PrepareBurger(specs);
return burger;
}
public abstract Burger CreateBurger();
} // BurgerFactory
public class ChickenBurgerFactory extends BurgerFactory {
@Override
public Burger CreateBurger() {
return new ChickenBurger();
}
} // Class
public class BeefBurgerFactory extends BurgerFactory {
@Override
public Burger CreateBurger() {
return new BeefBurger();
}
}
public interface Burger {
public void PrepareBurger(String[] specs); // Code to prepare Burger, cust spec
}
public class ChickenBurger implements Burger {
@Override
public void PrepareBurger(String[] specs) {
System.out.println("You ordered Chicken Burger with: " + "
");
System.out.println(Arrays.toString(specs));
}
} // class
public class BeefBurger implements Burger {
@Override
public void PrepareBurger(String[] specs) {
System.out.println("You ordered Beef Burger with: ");
System.out.println(Arrays.toString(specs));
}
}
public class Demo {
private static BurgerFactory myBurger;
private static Burger burger;
private static String[] attribs;
static void OrderMenu(String request, String[] attribs) {
String menu = request;
request = "com.next.level2."+request+"Factory";
try {
Class clazz = Class.forName(request);
Constructor cons = clazz.getConstructor();
myBurger = (BurgerFactory) cons.newInstance();
} catch(Exception e) {
System.out.println("Can not order..."+menu);
}
} // OrderMenu
static void eatMenu() {
burger = myBurger.makeBurger(attribs);
System.out.println(burger.getClass().getName());
}
public static void main(String[] args){
attribs = new String[] {"Pineapple", "Thin Crust", "Onion", "Mushroom"};
String request = "BeefBurger"; //"ChickenBurger" => could be anything or
// combination;
OrderMenu(request, attribs);
eatMenu();
} // main
} // Demo
1. Dropping item from Menu - code will work fine
2. For OCP - With new menu item (xxburger) another factory (VeggieBurgerFactory) and
VeggieBerger need to be added and Demo/Front end need to be modified.
3. Also if we want to limit endless creation of factories, do you think method overriding PrepareBurger might help ? Thanks much for your time.
My left ear is very upset.
We fixed the sound in newer videos xD
Let us know why you are upset and which parts where not clear, we will do our best to help! Cheers :)
pronounced "Eeeee-diom", not "Eye-diom"
Thanks for pointing that out!
I usually use an interface instead of an abstract class. An Interface means that I am creating a "contract" for all Restaurants and it´s mandatory that all the classes implementing it will implement the createBurguer.
An abstract class should be used for generalization of a behaviour, an interface for standardization, this case looks like standardization to me.
Meaning:
Generalizing: "All these classes seem to work this way, lets sum up common code in a common place"
Standardizing: "I want to enforce that all this classes behave this way"
What do you think about this approach and why would you favour the use of an abstract class over an interface?
I guess, interfaces enforce a contract, ensuring all implementing classes follow the same methods, making them ideal for standardizing behavior. Abstract classes, however, offer shared code, making them better for generalization when multiple classes need common functionality. They allow partial implementations and can be more flexible when evolving over time. So, imo choose interfaces when you need consistency across classes and abstract classes when you want to combine shared logic with enforced structure. Does this answer your question?
Great, thanks
nice vid, bad audio tho
Sorry to read that! But rest assured we are constantly working on improving the audio quality!
burge.prepare not checked for null