The Factory Method Pattern Explained and Implemented in Java | Creational Design Patterns | Geekific
Вставка
- Опубліковано 8 чер 2024
- Support us on Patreon: / geekific
GitHub Repository: github.com/geekific-official/...
Stay updated on our videos by subscribing to the channel and hitting the like button!
In the second video of this series we discuss, explain and implement one of the most used and most powerful Design Patterns out there: the Factory Method Design Pattern.
Timestamps:
00:00 Introduction
00:15 The Simple Factory Idiom
03:43 The Factory Method Pattern
06:50 Recap
07:34 Abstract Factory Method Teaser
08:18 Thanks for Watching!
If you found this video helpful, check other Geekific uploads:
- Introduction to Design Patterns: • What are Design Patter...
- What is a Thread? (Process, Program, Parallelism, Scheduler Explained): • What is a Thread? | Th...
- The Volatile and Synchronized Keywords in Java: • The Volatile and Synch...
- Object-Oriented Programming Fundamentals: • What is Object-Oriente...
- SOLID Principles and Best Practices: • SOLID Design Principle...
- The Factory Method Pattern Explained and Implemented in Java: • The Factory Method Pat...
- The Abstract Factory Pattern Explained and Implemented in Java: • The Abstract Factory P...
- The Singleton Pattern Explained and Implemented in Java: • The Singleton Pattern ...
#Geekific #DesignPatterns #FactoryMethodPattern #SimpleFactory #CreationalPatterns
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.
Super super helpful explanation, the code separated in boxes makes it more manageable to understand, thanks a lot! I'm totally subscribing
i have been watching your design patterns series for a couple of days and those videos are great!!! thanks and keep going
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.
Great explanation, to the point, clear and concise.
Unbelievable that such a great pattern explanation like this exists
I am understanding these design pattern videos so well . Thank you very much . We need teachers like you sir :)
Thank you, it was really easy to understand, and your method of explanation is probably one of the best!
Thank you so much for this progressive explanation of the Factory Method Pattern
Nice Video and nice Reverb!
Great video my friend, everything is explained so clearly.
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 :)
Very clear explanation. Thanks, a lot.
i wish i can express how helpful your videos are
You already did! :)
You should deserve more subscribers and views. Nice explanation!
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
You are great Dude! Happy I found your channel
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 :)
Superduper . Thanks a lot.
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 ...
Well explained, thanks!
Great video!!! Thank you
Really good explanation!
super simple explanation
what a great explanation
Legend, thank you!
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
thanks god we have you mate
Крутейшая связка, редко такой процент бывает
Great, thanks
well done. Nicely explained.
Glad it was helpful!
Perfect!
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.
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!
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()]
What if my restaurants wants to serve both types of burgers. You changed the problem statement in the second design pattern.
yes exactly!
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!
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 :)
What if you dont know the exact factory type at compile time?
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.
i really liked that you removed the veggie burger from the menu 👍
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!
I do not know what to say except thank you.
You are most welcome :)
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.
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...
This video made me hungry
we also need a delivery pattern
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!
I wish I could buy You a Burger 🍔 for Your Excellent Video 😀
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
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.
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!
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
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
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
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 :)
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 UA-cam, 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.
pronounced "Eeeee-diom", not "Eye-diom"
Thanks for pointing that out!
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.
nice vid, bad audio tho
Sorry to read that! But rest assured we are constantly working on improving the audio quality!