I hate the term 'rockstar developer', 'code ninja', but I think given your mastery of so many topics (and you need to have mastered something in order to teach it, although teaching can also be considered part of the learning process), you're probably one of the few people whom I would term a 'rockstar developer', 'code ninja'. But its not even just code, its adobe, intruments, cooking - you're like a one man udemy! Incredible!
The hardest part about the Abstract Factory is the number of classes involved. It has been said the human brain can only focus on 5 to 9 ideas at a time. If you can break them down into smaller pieces it should make sense. Don't worry, most programmers I come across can't explain how to use the Abstract factory. It was hard for me in the beginning but it opens up a whole new world for creating simulations
+Derek Banas In what situations would you use the abstract factory pattern? Are there situations where the regular factory pattern is better than the abstract factory pattern? Why did you use abstract classes and not interfaces?
I believe the Abstract Factory Pattern is just an extension of the basic factory pattern. It's the concept that you shoot for when you want to create a system where you want control of every single part. It breaks everything down so that you don't violate the single responsibility principle, or closed for edits open for plugins principle. Figuring out how to grasp when to use an interface over an abstract class is something I'm still working on.
Thank you for great tutorials. When watching them I recall this: Every programmer occasionally, when nobody's home, opens up a file on their computer. It's a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world. This file is Good Code. It has sensible and consistent names for functions and variables. It's concise. It doesn't do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry.
3:22 I think it is worth mentioning that in Java, when a method returns an abstract or interface type, it actually returns the subclass object that extends the abstract class or the object of a class that implements the interface respectively.
You're very welcome :) I did my best to make the gof patterns easy to understand both here and then again in the refactoring tutorial. I'm glad you like them
I just started watching your playlist on design patterns and I'm loving it. I'm taking Design Patterns class in school and your videos really help solidify the material. Thank you very much and keep doing what you're doing because you're good at it!
hey sir ! i got very low marx in my software design paterns exam.got the results today. so i came looking for tutorials as i dont get any of the design paterns n i came acros these tutorials of urs. n i found them very useful so far. hope thy help me in geting a good understanding of wat design paterns are n in passing my finals :)
One of the DP most difficult to understand. Your diagrams have helped me a lot. Thanks so much for the neat presentation and teaching strategy design. It is much appreciated.
3:20 , UFOenemyShip , RocketEnemyShip , BigUFOEnemyship are not abstract classes. They are concrete classes , the instances of which are being held by a reference of a common parent (In this case , the abstract class EnemyShip) in the main function
No, you are a good teacher. Its just me... After watching a video I go back and watch it again, and 99% of the time, I get what I didn't the second time...
Thank you :) Yes, these videos are best viewed with the code printed out beforehand. Then if notes are taken during the video on the code in your own words everything should stick. I also covered the Abstract Factory at the end of my refactoring tutorial
I am a novice in the world of software engineering working with java and php was having hard time getting hold of concept of design patterns. After watching this videos atleast am able to explain the concept hopefully should be able to implement it after practicing a bit. thank you
Thank you very much for the referrals :) I looked at all the books available on patterns so that the series would hopefully help everyone regardless of the book they use. I'm very happy that it has helped as a supplement
I think your video tutorials should be cited and pinned for students or who-ever in their design pattern study material. People should be open on that. Thank you
Really appreciate your tutorials. You have a knack for explaining these complex patterns in a relatable and understandable way. I especially like your examples and how you have separated and broken each component down to better illustrate how everything fits together as a whole. Keep up the awesome tutorials.
This is a great video, took a bit of rewatching to really get it but pausing and taking notes on each part really helped. Seems to me that it's essentially the Factory pattern inside another Factory pattern (Factory-ception). You have an object made up of multiple parts, each part (engine, weapon etc) created using a Factory pattern (i.e. Weapons are made using Weapon Factory), but these parts Factories are then called inside an overall Factory. So essentially you're calling a Factory that then uses another Factory for each part, which is a really neat idea.
Your series of videos are fantastic. Clean, concise and to the point. They've helped me out massively throught my university course, so thank you Mr Banas!
This is an amazing explanation! Note to other viewers.... you have to understand how abstract classes / methods work in order to get how abstract factories work.
It feels complicated indeed, but It's actually mot much diffrent than the normal factory, just that this time not only the Ships are abstracted, but also the Factories. So you now have another layer that chooses which Factory are you going to use, and only then you refer to the making of the Ship with that factory. The idea is that u might have several factories that each of them make ships diffrently so you therefore abstract this layer too. So In this video we have 2 factories: one that creates BossShip components, and one that creates NormalShip components. Notice that the ship constructor now recieves a factory argument which tells it which factory to use for the making of it's parts. Hope this made it alittle clearer.
Some things that may help : Take a look at the code on my site. I also have the diagram there. I also covered the Abstract Factory again in this tutorial newthinktank. com/2013/02/code-refactoring-18-2/ This is considered the most complex of design patterns. You don't use it all that much
Hey Derek! Love your vids. Could you please provide a UML diagram for this design pattern? Also, in main() we have EnemyShipBuilding MakeUFOs = new UFOEnemyShipBuilding(); which implies that we know that we are building a UFO (as opposed to a rocket ship). Doesn't this kind of go against the whole idea of dynamically choosing objects? Thanks in advance.
That sounds good to me. I some times don't optimize everything because I'm just trying to get the basic idea across. I revisit the abstract pattern in my refactoring tutorial as well.
Your tutorials are pretty superb on the whole, however I actually think you teach this lesson kinda back-to-front. If you follow this demo through in the direction you posit, you only really have something whole by the end. My brain wants to start at: what are enemy ships made of? then how are the different enemy ship components made? then how are the enemy ship parts put together? then how are the requests for enemy ships put together.
I realise that the above sounded more critical than intended :) I do genuinely think your tutorials are superb! And, in your defence, abstract factory patterns are fiddly things whichever way you come at them! I actually found I got it best in the end just walking through it with a debugger. The pertinent take-home message for those that are struggling with it is to appreciate the modularity of being able to exchange the factories that build the UFO's constituent parts. Because the UFO is calling an abstracted Factory, it can be chopped and changed to a different factory at some later stage. For example: hey, you're months into your development and you suddenly decide that the UFO type is actually best suited to have the same kinds of components as the Rockets ... no problem, just switch out the factory that tells the UFO what it should be made of. No problem! Your requests in Main are untouched as are your program's requests to actually build the UFOs.
I agree with you. The best way if you do not understand something is to debug it ! It always helps me too ! By the way, with the provided code, this tutorial is good enough !
Necroing this but yeah. I had the same feeling. The best way to explain this here would be to explain that the specific ship classes have a factory that builds what they need to have to not just be a generic ship. The factory doesn't build the specific ship but each ship is defined by how the factory creates the missing parts them. Something like that
You're very welcome :) I definitely don't do this for money. You'd laugh if you saw how much I make. It is very gratifying however to me to be able to help people all over the world!
Many people are confused by this video. I can understand why. The simplified way to view the Abstract Factory Pattern is that an Abstract Factory is a factory that creates other factories. In the previous video (Factory Pattern) it was illustrated a factory of enemy ships. So the business had (initially) one product of different varieties. Later on, the business grew to the point where different types (families) of products are provided. Modifying the EnemyShipFactory to create Weapons will be incorrect because a Weapon and an EnemyShip are two different things. Therefore, you would 1) Create the WeaponsFactory with the different flavors of weapons, and 2) you would create Factory that can create dynamically either the EnemyShipFactory or the WeaponsFactory depending of the kind of order that was placed.
Thanks :) I think I'm going to have to cover UML. I only avoided the normal UML diagrams this time because I thought the pictures might help. I'm definitely going to cover real world topics as soon as I get the basics down. I wish I could get this to work more like a lecture with people asking questions but that doesn't seem to ever work. This is just the beginning. I constantly change my teaching style based on input. Thanks for that
This was the main one I struggled to understand in class.. Starting to understand it, but it's not there yet. Probably just takes time, definitely gonna dive in to the code. Thank you!
Hi Derek, Could you please suggest me some good book on Object Oriented Software Design which has sufficient practice sets other than Head First. I already own Head First book. Thanks
I provide another example of using this pattern in the very last video in my refactoring tutorial. I use this pattern very often when I'm building simulations. These tutorials mainly came from the GOF book, but I used many of my personal notes as well
Thank you so much for your videos! I was really confused trying to understand the difference between the factory and facade patterns (since my professor didn't do a good job of explaining it), so your factory design pattern videos saved me before the midterm. Your videos are the best.
This is really awesome! First, I read a chapter in the book head fists design patterns then watching your educational tutorial to brighten things up. And it works. Learning design patterns will become easy thanks to you. I will Recommend your channel to everyone. And thank you for doing this!
Hello Derek, I am so happy to have found this pattern explanations. Finally I can learn to understand them clearly. And there is this one question nobody could ever answer me, but you can: Why maybe every plugin in wordpress starts with a static init method
Hello Derek, nice video. Good graphics. While the video does a good job of explaining how an abstract video works, it wasn't until I looked at the code that I started to understand the value of the factory. It wasn't until I saw that enemy ships took in the factory in it's constructor, that it became clear the role of the factory. I was going under the false presumption that the factory in the abstract factory pattern behaved the same as the one in the normal factory pattern.
I have a suggestion for you (and for every professor in HS and in Uni): when presenting code in PowerPoint, or other presentation software, try to include the code with syntax highlighting. It really helps to differentiate the parts of the code, the keywords, and the variable names. It really frustrates me when I see black-and-white code in presentations - syntax highlighting is one of the reasons why we do not program in plain Notepad... Use for example Carbon, or Polacode - or just simply take a screenshot of the code in your IDE / Text Editor. I really appreciate your time and dedication to these videos, though - it really helps me a lot! So keep up the good work! :-)
I'll be revisiting this pattern in my refactoring tutorial. I should have kept the pattern in a simpler form. Also I think I didn't spend enough time explaining that patterns can take on many different forms. I'll correct that as well
I am probably very late in commenting this video. I watched so many of your videos, i loved them all. but this one you really went that extra mile with the diagrams which are really awesome. I wished all the videos had that methodology. (one thing to add, is that the code you present isnt colorized anymore. although it is a small detail, i reallized code is actually harder to read whitout that purple font on the keywords). But, again, awesome video!
An abstract class is normally a class that wouldn't make sense to turn it into an object. What would an animal object look like? A dog object definitely makes sense though. Abstract classes are used to abstract out what is the same for all subclasses. It is also used to allow for polymorphic tricks. Concrete classes are made to be used as objects. Does that make sense?
Hi Derek, at 3:21 you said UFOEnemyship() is abstract class. And we can not create abstract class object then how can we return an object of abstract class with new ? can you please explain it to me?
Hey Derek, not sure if you go into this later in your tutorial series but why don't you use public static ENUM's in your factories that define what type of ships are available? So You could use UFOEnemyShipBuilding.makeEnemyShip(UFOEnemyShipBuilding.SHIPS.UFO_BOSS) to create a UFO Boss ship. This will prevent typos in ship types, and also provide a nice list inside a developers IDE on which ship types are available.
At 3:20 it's best to use a CASE block statement for the tutorial, though it wouldn't be scalable because when adding new objects you'll have to update the "EnemyShipFactory" class AND whichever class it is defining. Ideally you would want Extensibility ( or MethodOverriding ) to simplify this. Just my thought.
Derek, If I want to add an additional power to the Boss Ship , say Missiles.I will have to add an extra function called "addMissile()" in the EnemyShipFactory class (and not in the UFOBossEnemyShipFactory class) so that polymorphism works. If the above is correct then wont this extra function be redunded for normal enemy space ships (wasting extra memory).?
+Harsh Chaudhari Yes, I was wondering the same thing. Without giving it much thought right now, perhaps you could have multiple abstract EnemyShipFactory classes. Then, in the concrete EnemyShipBuilding class, you could use the appropriate abstract EnemyShipFactory class for each UFO with different parts.
Once again your explanation is crystal clear. Congrats! This time I have a very interesting question (I believe), that is... How is you Entity Relation Diagram going to be if those objects need to be database Entities (because you need to persist them)?Let me elaborate onto this idea: At the beginning, you create a table to represent the abstract class, for instance EnemyShip, so you add a name column and create a Foreign Key to ESWeapon and ESEngine. So far so good, but what happens when you EvilEnemyShip concrete class (which has a new float property 'turbo') needs to be persisted? Never found a "right answer" to this question, though I have come up with 2 different approaches: 1. You add a 'turbo' column to the EnemyShip table and use it only when needed (ie: on EvilEnemyShip objects) and in any other case you just persist a null value. Ok this may work but it has some remarkable drawbacks: - You need to add every EnemyShip specific implementation columns to the EnemyShip table to support its persistance in the DB. This means that the number of TABLE COLUMNS MAY GROW REALLY FAST, and MOST OF THEM COULD BE NULL! - At first glance, you can't for sure know what type of specific EnemyShip is for a given tuple. This can easily lead to errors if logic is not consistently implemented in you program code. However, this problem can be solved adding an extra column 'type' where you store which specific EnemyShip it is. 2. For every new specific EnemyShip implementation you create a new table, for instance the EvilEnemyShip table, and you add every extra column needed to this table to persist all its properties. Then you add a Foreing Key in the EnemyShip table to the EvilEnemyShip. I have come up with this approach to mitigate the problems described in the first approach: - Now EnemyShip table columns will only increase at most 1 for every specific implementation. Note that this only decrease the number of new columns but you still are going to have a lot of null values. On the other hand, it is the number of tables that is going to increase in 1 for every EnemyShip specific implementation. Is this tradeoff better? Can't tell. THIS IS WHAT I'M DYING TO KNOW. - You can tell which specific EnemyShip implementation a tuple is based on the Foreign Key that is not null for a given tuple. Hope yours or somebody else's expertise can help me with this life or death doubt 😂
Feels like , Abstract factory pattern is used when we have various factories producing different things and we don't want client to decide which factory object it should consult to make a product, rather than just delegate the process of making an object to the wrapper of all factories , which will have the logic of deciding which factory to consult on order to make the right object. It makes me remind if Facade Pattern as well, in this case the Facade will encapsulate all the factories.
Thank you for these, It is much appreciated. This format however is great in addition to the other format would be better. I find showing the code helps that much better. That being said, thanks again and keep up the great work.
That was great video, but I think in this case would be better to add to Factory such method "addParts(EnemyShip ship) { ship.setWeapon(addESGun()); ship.setESEngine(addESEngine()); }. Then, you don't have to put factory in Ship's constructor and copy-paste for every ship the same code that uses this factory. What do you think about this?
I think that is a great idea :) Most of the times the code isn't optimized because I write most of this code off of a sequence diagram out of my head. Thank you for the input.
Derek, one thing that confused me a lot is that you refer to the abstract class and/or interface like this would be 'created', but you create a concrete class that extends the abstract class or implements the interface. So the factory will not 'shoot abstract enemy ships' but concrete ships that will be treated as abstract... I know that it "shoots abstract" but using the concrete... For me it was very difficult to understand that in the "pseudo UML" image, because it is linear, I think.
It just seems so complicated. I guess for now I'm happy to know that this is possible and I'll watch it again if I find myself needing this. But great job anyway :)
Thank you :) Yes learning Design Patterns and Refactoring is pretty high end programming. Very often the most important part about learning them is to learn when not to use them.
I just made every pattern in the gof book. I tried to create them so that they could be used as self contained videos and didn't require the viewer to watch all of the others. The factory patterns seem to confuse people the most
Thank you :) I put everything on my website. What benefit would there be in putting them on GitHub? The way it is set up now, people can access the code and the video on the same page
I'm just trying to demonstrate the pattern while trying to keep everything as easy to understand as possible. At the end of my refactoring tutorial I provide another better version of this pattern
It is another layer of abstraction that is commonly used. The design patterns can come in different forms though. This is an example of the GOF pattern. I provide another example on the Abstract Factory at the end of my refactoring tutorial (Last Video). It may help to see it in a few ways
Learn in One Videos for Every Programming Language
Subscribe to Bookmark them: bit.ly/2FWQZTx
C++ : ruclips.net/video/Rub-JsjMhWY/видео.html
Python : ruclips.net/video/N4mEzFDjqtA/видео.html
Java : ruclips.net/video/n-xAqcBCws4/видео.html
PHP : ruclips.net/video/7TF00hJI78Y/видео.html
MySQL : ruclips.net/video/yPu6qV5byu4/видео.html
JavaScript : ruclips.net/video/fju9ii8YsGs/видео.html
C# : ruclips.net/video/lisiwUZJXqQ/видео.html
HTML5 : ruclips.net/video/kDyJN7qQETA/видео.html
CSS3 : ruclips.net/video/CUxH_rWSI1k/видео.html
JQuery : ruclips.net/video/BWXggB-T1jQ/видео.html
TypeScript : ruclips.net/video/-PR_XqW9JJU/видео.html
ECMAScript : ruclips.net/video/Jakoi0G8lBg/видео.html
Swift : ruclips.net/video/dKaojOZ-az8/видео.html
R : ruclips.net/video/s3FozVfd7q4/видео.html
Haskell : ruclips.net/video/02_H3LjqMr8/видео.html
Handlebars : ruclips.net/video/4HuAnM6b2d8/видео.html
Bootstrap : ruclips.net/video/gqOEoUR5RHg/видео.html
Rust : ruclips.net/video/U1EFgCNLDB8/видео.html
Matlab : ruclips.net/video/NSSTkkKRabI/видео.html
Arduino : ruclips.net/video/QO_Jlz1qpDw/видео.html
Crystal : ruclips.net/video/DxFP-Wjqtsc/видео.html
Emacs : ruclips.net/video/Iagbv974GlQ/видео.html
Clojure : ruclips.net/video/ciGyHkDuPAE/видео.html
Shell : ruclips.net/video/hwrnmQumtPw/видео.html
Perl : ruclips.net/video/WEghIXs8F6c/видео.html
Perl6 : ruclips.net/video/l0zPwhgWTgM/видео.html
Elixir : ruclips.net/video/pBNOavRoNL0/видео.html
D : ruclips.net/video/rwZFTnf9bDU/видео.html
Fortran : ruclips.net/video/__2UgFNYgf8/видео.html
LaTeX : ruclips.net/video/VhmkLrOjLsw/видео.html
F# : ruclips.net/video/c7eNDJN758U/видео.html
Kotlin : ruclips.net/video/H_oGi8uuDpA/видео.html
Erlang : ruclips.net/video/IEhwc2q1zG4/видео.html
Groovy : ruclips.net/video/B98jc8hdu9g/видео.html
Scala : ruclips.net/video/DzFt0YkZo8M/видео.html
Lua : ruclips.net/video/iMacxZQMPXs/видео.html
Ruby : ruclips.net/video/Dji9ALCgfpM/видео.html
Go : ruclips.net/video/CF9S4QZuV30/видео.html
Objective C : ruclips.net/video/5esQqZIJ83g/видео.html
Prolog : ruclips.net/video/SykxWpFwMGs/видео.html
LISP : ruclips.net/video/ymSq4wHrqyU/видео.html
Express : ruclips.net/video/xDCKcNBFsuI/видео.html
Jade : ruclips.net/video/l5AXcXAP4r8/видео.html
Sass : ruclips.net/video/wz3kElLbEHE/видео.html
Derek It's very much confusing .
I hate the term 'rockstar developer', 'code ninja', but I think given your mastery of so many topics (and you need to have mastered something in order to teach it, although teaching can also be considered part of the learning process), you're probably one of the few people whom I would term a 'rockstar developer', 'code ninja'. But its not even just code, its adobe, intruments, cooking - you're like a one man udemy! Incredible!
All that I require is a thank you :) I have no need for money. I'm just happy that you enjoy the videos and that they help. Please dont ever donate
The hardest part about the Abstract Factory is the number of classes involved. It has been said the human brain can only focus on 5 to 9 ideas at a time. If you can break them down into smaller pieces it should make sense. Don't worry, most programmers I come across can't explain how to use the Abstract factory. It was hard for me in the beginning but it opens up a whole new world for creating simulations
I understood your other videos. This one confused me.
David Wells Sorry about that. Feel free to ask questions. This pattern can be quite confusing.
This is the best video I've seen so far. I'm actually shocked that you got confused here.
Guru G Ahahahahaha. Yeah, that's true! 😁
+Derek Banas
In what situations would you use the abstract factory pattern?
Are there situations where the regular factory pattern is better than the abstract factory pattern?
Why did you use abstract classes and not interfaces?
I believe the Abstract Factory Pattern is just an extension of the basic factory pattern. It's the concept that you shoot for when you want to create a system where you want control of every single part. It breaks everything down so that you don't violate the single responsibility principle, or closed for edits open for plugins principle. Figuring out how to grasp when to use an interface over an abstract class is something I'm still working on.
this is so deep in layers of abstraction that I can almost see Adele rolling in it
Thank you for great tutorials. When watching them I recall this:
Every programmer occasionally, when nobody's home, opens up a file on their computer. It's a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world. This file is Good Code. It has sensible and consistent names for functions and variables. It's concise. It doesn't do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry.
You definitely have a way with words :) I agree through design patterns and refactoring we can create truly beautiful code.
You are a programmer in poet's body.
and it is Hello World
@@groadybones LOL! you nailed it! XD
Thank you :) I used to really mix up the tutorials, but lately I have just been getting programming requests. I'm glad you like them
You are very welcome :) I'm extremely happy that you found the videos useful
3:22 I think it is worth mentioning that in Java, when a method returns an abstract or interface type, it actually returns the subclass object that extends the abstract class or the object of a class that implements the interface respectively.
Guess I'm gonna go work at McDonalds instead.
Haaa haa
I want a bug ufo burger, please
Why are you running @PrimeTime? Come back and make me a Big UFO burger.
Never give up! Didn't get it? Try again!
You're very welcome :) I did my best to make the gof patterns easy to understand both here and then again in the refactoring tutorial. I'm glad you like them
I just started watching your playlist on design patterns and I'm loving it. I'm taking Design Patterns class in school and your videos really help solidify the material. Thank you very much and keep doing what you're doing because you're good at it!
***** Thank you for the nice compliments :) I did my best to clear up this complicated topic.
You're very welcome :) If you work on this pattern all of the others will be simple to use. This is about as complicated as they get
You are very welcome :) Thank you very much for the kind message. I'm happy to help
hey sir ! i got very low marx in my software design paterns exam.got the results today. so i came looking for tutorials as i dont get any of the design paterns n i came acros these tutorials of urs. n i found them very useful so far. hope thy help me in geting a good understanding of wat design paterns are n in passing my finals :)
vivid + clear explanation, you get the big picture first before diving into the code. I really like this tutorial !
Thank you :) I'm glad it helped
One of the DP most difficult to understand. Your diagrams have helped me a lot. Thanks so much for the neat presentation and teaching strategy design. It is much appreciated.
fallback R Thank you :) I'm very happy that I could help
3:20 , UFOenemyShip , RocketEnemyShip , BigUFOEnemyship are not abstract classes. They are concrete classes , the instances of which are being held by a reference of a common parent (In this case , the abstract class EnemyShip) in the main function
understand me please @Sravani
@sravani yes absolutely.
No, you are a good teacher. Its just me... After watching a video I go back and watch it again, and 99% of the time, I get what I didn't the second time...
I understand why a lot of people are complaining about the UML diagram but i found the analogy to be very helpful, thank you.
Thank you :)
Thank you :) Yes, these videos are best viewed with the code printed out beforehand. Then if notes are taken during the video on the code in your own words everything should stick. I also covered the Abstract Factory at the end of my refactoring tutorial
Came here to learn more for the programming I do for a living.
Got an universe of insights for the programming I do for a passion.
Thank you :) I'm very happy that I could help
I am a novice in the world of software engineering working with java and php was having hard time getting hold of concept of design patterns. After watching this videos atleast am able to explain the concept hopefully should be able to implement it after practicing a bit. thank you
+Shaheel Gani You're very welcome :) I'm happy that I could clear up design patterns.
You're very welcome :) I'm glad you liked it
Thank you very much for the referrals :) I looked at all the books available on patterns so that the series would hopefully help everyone regardless of the book they use. I'm very happy that it has helped as a supplement
I think your video tutorials should be cited and pinned for students or who-ever in their design pattern study material. People should be open on that. Thank you
Thank you :) I'm happy you have found them helpful.
I'm not all that smart. I just don't have any other hobbies. You're very welcome :) Im very happy that you enjoy them
Really appreciate your tutorials. You have a knack for explaining these complex patterns in a relatable and understandable way. I especially like your examples and how you have separated and broken each component down to better illustrate how everything fits together as a whole. Keep up the awesome tutorials.
Thank you for the compliment :) I do my best to keep the videos fun and understandable.
This is a great video, took a bit of rewatching to really get it but pausing and taking notes on each part really helped.
Seems to me that it's essentially the Factory pattern inside another Factory pattern (Factory-ception). You have an object made up of multiple parts, each part (engine, weapon etc) created using a Factory pattern (i.e. Weapons are made using Weapon Factory), but these parts Factories are then called inside an overall Factory. So essentially you're calling a Factory that then uses another Factory for each part, which is a really neat idea.
You're very welcome :) I'm glad you found it useful
2022 and this is still relevant. Thanks man
Thank you for taking the time to tell me I helped :) I appreciate it!
Thank you :) I'm very happy that I seem to be helping people with this topic
I got it all loaded into Eclipse it makes it easier to follow what you did, wow 15 classes.
Yes that would be very accurate. The aren't very common. I show another example of how to use them in the last video in my refactoring tutorial
Your series of videos are fantastic. Clean, concise and to the point. They've helped me out massively throught my university course, so thank you Mr Banas!
This is an amazing explanation!
Note to other viewers.... you have to understand how abstract classes / methods work in order to get how abstract factories work.
Thank you :)
I understand clearly nothing!
Zor amk ya :D
same just wasted 26 minutes by watching the video twice
It feels complicated indeed, but It's actually mot much diffrent than the normal factory, just that this time not only the Ships are abstracted, but also the Factories. So you now have another layer that chooses which Factory are you going to use, and only then you refer to the making of the Ship with that factory.
The idea is that u might have several factories that each of them make ships diffrently so you therefore abstract this layer too.
So In this video we have 2 factories: one that creates BossShip components, and one that creates NormalShip components. Notice that the ship constructor now recieves a factory argument which tells it which factory to use for the making of it's parts.
Hope this made it alittle clearer.
@@eliranmichaeli1580 thank you
:D
You're very welcome :) EnemyShipBuilding just provides a utility use and separates the code in to smaller pieces
I very much appreciate the kind words :)
Some things that may help : Take a look at the code on my site. I also have the diagram there. I also covered the Abstract Factory again in this tutorial newthinktank. com/2013/02/code-refactoring-18-2/
This is considered the most complex of design patterns. You don't use it all that much
wow, after jumping straight from factory method pattern, it got to a whole new level. I am in "repeat mode" till i master this pattern . XD
+GNAW GMT Yes the patterns get much more complicated. I did my best to make them understandable so you can then move on to the GOF book.
That is right. It just contains many factories that make different dynamic objects
Hey Derek! Love your vids. Could you please provide a UML diagram for this design pattern? Also, in main() we have EnemyShipBuilding MakeUFOs = new UFOEnemyShipBuilding(); which implies that we know that we are building a UFO (as opposed to a rocket ship). Doesn't this kind of go against the whole idea of dynamically choosing objects? Thanks in advance.
T-Bag
That sounds good to me. I some times don't optimize everything because I'm just trying to get the basic idea across. I revisit the abstract pattern in my refactoring tutorial as well.
Your tutorials are pretty superb on the whole, however I actually think you teach this lesson kinda back-to-front. If you follow this demo through in the direction you posit, you only really have something whole by the end. My brain wants to start at: what are enemy ships made of? then how are the different enemy ship components made? then how are the enemy ship parts put together? then how are the requests for enemy ships put together.
+Jon Edwards Thank you :) Yes there is always room for me to improve. I should have spent more time documenting everything in UML.
I realise that the above sounded more critical than intended :) I do genuinely think your tutorials are superb! And, in your defence, abstract factory patterns are fiddly things whichever way you come at them!
I actually found I got it best in the end just walking through it with a debugger.
The pertinent take-home message for those that are struggling with it is to appreciate the modularity of being able to exchange the factories that build the UFO's constituent parts. Because the UFO is calling an abstracted Factory, it can be chopped and changed to a different factory at some later stage.
For example: hey, you're months into your development and you suddenly decide that the UFO type is actually best suited to have the same kinds of components as the Rockets ... no problem, just switch out the factory that tells the UFO what it should be made of. No problem! Your requests in Main are untouched as are your program's requests to actually build the UFOs.
+Jon Edwards Thanks for the comment pointing out the usecase :))
I agree with you. The best way if you do not understand something is to debug it ! It always helps me too !
By the way, with the provided code, this tutorial is good enough !
Necroing this but yeah. I had the same feeling.
The best way to explain this here would be to explain that the specific ship classes have a factory that builds what they need to have to not just be a generic ship.
The factory doesn't build the specific ship but each ship is defined by how the factory creates the missing parts them.
Something like that
You're very welcome :) I definitely don't do this for money. You'd laugh if you saw how much I make. It is very gratifying however to me to be able to help people all over the world!
Many people are confused by this video. I can understand why. The simplified way to view the Abstract Factory Pattern is that an Abstract Factory is a factory that creates other factories.
In the previous video (Factory Pattern) it was illustrated a factory of enemy ships. So the business had (initially) one product of different varieties. Later on, the business grew to the point where different types (families) of products are provided. Modifying the EnemyShipFactory to create Weapons will be incorrect because a Weapon and an EnemyShip are two different things. Therefore, you would 1) Create the WeaponsFactory with the different flavors of weapons, and 2) you would create Factory that can create dynamically either the EnemyShipFactory or the WeaponsFactory depending of the kind of order that was placed.
It was very helpful clarifying the connection to the previous video.. thank you very much!
Really well explained
Thank you very much :) I have been practicing for a while at this. I am very happy if anything I do may help you or others teach better.
Thanks :) I think I'm going to have to cover UML. I only avoided the normal UML diagrams this time because I thought the pictures might help. I'm definitely going to cover real world topics as soon as I get the basics down. I wish I could get this to work more like a lecture with people asking questions but that doesn't seem to ever work. This is just the beginning. I constantly change my teaching style based on input. Thanks for that
You put a lot of effort into this, thank you for that. Made my exam prep a breeze.
JFrame I'm glad that I could help :) Best of luck on your exams
This was the main one I struggled to understand in class.. Starting to understand it, but it's not there yet. Probably just takes time, definitely gonna dive in to the code. Thank you!
Yes it is a complex pattern. You'll get it
All credit goes to seniors like you !!! :-)
Thank you :) I think I improved on this tutorial in the final part of my refactoring tutorial. Sorry about the confusion
this video is so freakin golden it's insane..
5th time watching it today, still keep going 'oh hey..' every few minutes while watching..
Thank you for taking the time to tell me you like it. It was a fun series of videos to make.
Derek your videos gives a total insight. Kudos to your effort for making such quality stuff specially for codes :)
Thank you for the nice compliment :)
Hi Derek,
Could you please suggest me some good book on Object Oriented Software Design which has sufficient practice sets other than Head First. I already own Head First book.
Thanks
I provide another example of using this pattern in the very last video in my refactoring tutorial. I use this pattern very often when I'm building simulations. These tutorials mainly came from the GOF book, but I used many of my personal notes as well
Thank you so much for your videos! I was really confused trying to understand the difference between the factory and facade patterns (since my professor didn't do a good job of explaining it), so your factory design pattern videos saved me before the midterm. Your videos are the best.
Thank you for taking the time to write me such a nice message :) I greatly appreciate it!!!
@@derekbanas and thank you for your work!
This is really awesome!
First, I read a chapter in the book head fists design patterns then watching your educational tutorial to brighten things up. And it works. Learning design patterns will become easy thanks to you.
I will Recommend your channel to everyone.
And thank you for doing this!
"Well hello internet!"
Greatest intro on the internet
Great tutorial! When you read the code and go through it, it all makes perfect sense. Thank you!
+Justine Lo Thank you :) I'm glad it helped
Hello Derek, I am so happy to have found this pattern explanations. Finally I can learn to understand them clearly. And there is this one
question nobody could ever answer me, but you can: Why maybe every plugin in wordpress starts with a static init method
Yes you are very intelligent :) You definitely are getting the idea. All of your comments have been very insightful
Hello Derek, nice video. Good graphics. While the video does a good job of explaining how an abstract video works, it wasn't until I looked at the code that I started to understand the value of the factory. It wasn't until I saw that enemy ships took in the factory in it's constructor, that it became clear the role of the factory. I was going under the false presumption that the factory in the abstract factory pattern behaved the same as the one in the normal factory pattern.
I have a suggestion for you (and for every professor in HS and in Uni): when presenting code in PowerPoint, or other presentation software, try to include the code with syntax highlighting. It really helps to differentiate the parts of the code, the keywords, and the variable names. It really frustrates me when I see black-and-white code in presentations - syntax highlighting is one of the reasons why we do not program in plain Notepad... Use for example Carbon, or Polacode - or just simply take a screenshot of the code in your IDE / Text Editor.
I really appreciate your time and dedication to these videos, though - it really helps me a lot! So keep up the good work! :-)
Thank you for the input :)
This is really well laid out Derek, Really great job!
Cal Ferns Thank you :) I did my best
I'll be revisiting this pattern in my refactoring tutorial. I should have kept the pattern in a simpler form. Also I think I didn't spend enough time explaining that patterns can take on many different forms. I'll correct that as well
I am probably very late in commenting this video. I watched so many of your videos, i loved them all. but this one you really went that extra mile with the diagrams which are really awesome. I wished all the videos had that methodology.
(one thing to add, is that the code you present isnt colorized anymore. although it is a small detail, i reallized code is actually harder to read whitout that purple font on the keywords).
But, again, awesome video!
Thank you for taking the time to tell me you're enjoying the videos :)
Thank you for those detailed code and examples!
I'm very happy that they help :)
An abstract class is normally a class that wouldn't make sense to turn it into an object. What would an animal object look like? A dog object definitely makes sense though. Abstract classes are used to abstract out what is the same for all subclasses. It is also used to allow for polymorphic tricks. Concrete classes are made to be used as objects. Does that make sense?
Thank you :) It is very exciting to be able to help people all over the world!
You use it to create more robust dynamic objects. Play around with the idea and you'll get it
you should have included uml diagram
:(
Hi Derek,
Thank you very much for this series of video. They are very good to understand through your demo.
James Li You're very welcome :) I'm happy that I could help.
Hi Derek, at 3:21 you said UFOEnemyship() is abstract class. And we can not create abstract class object then how can we return an object of abstract class with new ? can you please explain it to me?
it s not an abstract class it s a concrete class , he just misspoke :)
Thank you very much :) Yes I wish I would have made more examples. I plan on revisiting design patterns when I cover C++
Hey Derek, not sure if you go into this later in your tutorial series but why don't you use public static ENUM's in your factories that define what type of ships are available? So You could use UFOEnemyShipBuilding.makeEnemyShip(UFOEnemyShipBuilding.SHIPS.UFO_BOSS) to create a UFO Boss ship. This will prevent typos in ship types, and also provide a nice list inside a developers IDE on which ship types are available.
You're very welcome :) I'm happy I was able to help!
At 3:20 it's best to use a CASE block statement for the tutorial, though it wouldn't be scalable because when adding new objects you'll have to update the "EnemyShipFactory" class AND whichever class it is defining. Ideally you would want Extensibility ( or MethodOverriding ) to simplify this. Just my thought.
Just noticed this video is a decade old lol
Derek,
If I want to add an additional power to the Boss Ship , say Missiles.I will have to add an extra function called "addMissile()" in the EnemyShipFactory class (and not in the UFOBossEnemyShipFactory class) so that polymorphism works. If the above is correct then wont this extra function be redunded for normal enemy space ships (wasting extra memory).?
+Harsh Chaudhari Yes, I was wondering the same thing. Without giving it much thought right now, perhaps you could have multiple abstract EnemyShipFactory classes. Then, in the concrete EnemyShipBuilding class, you could use the appropriate abstract EnemyShipFactory class for each UFO with different parts.
Once again your explanation is crystal clear. Congrats!
This time I have a very interesting question (I believe), that is... How is you Entity Relation Diagram going to be if those objects need to be database Entities (because you need to persist them)?Let me elaborate onto this idea:
At the beginning, you create a table to represent the abstract class, for instance EnemyShip, so you add a name column and create a Foreign Key to ESWeapon and ESEngine. So far so good, but what happens when you EvilEnemyShip concrete class (which has a new float property 'turbo') needs to be persisted?
Never found a "right answer" to this question, though I have come up with 2 different approaches:
1. You add a 'turbo' column to the EnemyShip table and use it only when needed (ie: on EvilEnemyShip objects) and in any other case you just persist a null value. Ok this may work but it has some remarkable drawbacks:
- You need to add every EnemyShip specific implementation columns to the EnemyShip table to support its persistance in the DB. This means that the number of TABLE COLUMNS MAY GROW REALLY FAST, and MOST OF THEM COULD BE NULL!
- At first glance, you can't for sure know what type of specific EnemyShip is for a given tuple. This can easily lead to errors if logic is not consistently implemented in you program code. However, this problem can be solved adding an extra column 'type' where you store which specific EnemyShip it is.
2. For every new specific EnemyShip implementation you create a new table, for instance the EvilEnemyShip table, and you add every extra column needed to this table to persist all its properties. Then you add a Foreing Key in the EnemyShip table to the EvilEnemyShip. I have come up with this approach to mitigate the problems described in the first approach:
- Now EnemyShip table columns will only increase at most 1 for every specific implementation. Note that this only decrease the number of new columns but you still are going to have a lot of null values. On the other hand, it is the number of tables that is going to increase in 1 for every EnemyShip specific implementation. Is this tradeoff better? Can't tell. THIS IS WHAT I'M DYING TO KNOW.
- You can tell which specific EnemyShip implementation a tuple is based on the Foreign Key that is not null for a given tuple.
Hope yours or somebody else's expertise can help me with this life or death doubt 😂
I do my best. I'm very happy it helped you :)
Thank you :) I'm doing my best to make design patterns understandable
Feels like , Abstract factory pattern is used when we have various factories producing different things and we don't want client to decide which factory object it should consult to make a product, rather than just delegate the process of making an object to the wrapper of all factories , which will have the logic of deciding which factory to consult on order to make the right object.
It makes me remind if Facade Pattern as well, in this case the Facade will encapsulate all the factories.
What a great presentation of design patterns - demystifying...... Great job
Derek I am C# .Net Developer...I am following 100%....Awesome stuff....
abhijeet girase Great I'm very happy that it is helping :)
Thank you for these, It is much appreciated. This format however is great in addition to the other format would be better. I find showing the code helps that much better. That being said, thanks again and keep up the great work.
I really like your videos. You are doing a great job.
That was great video, but I think in this case would be better to add to Factory such method "addParts(EnemyShip ship) { ship.setWeapon(addESGun()); ship.setESEngine(addESEngine()); }. Then, you don't have to put factory in Ship's constructor and copy-paste for every ship the same code that uses this factory. What do you think about this?
I think that is a great idea :) Most of the times the code isn't optimized because I write most of this code off of a sequence diagram out of my head. Thank you for the input.
thanks for sharing the knowledge. it really helps. was looking for some tutorial like these.
You're very welcome :)
Derek, one thing that confused me a lot is that you refer to the abstract class and/or interface like this would be 'created', but you create a concrete class that extends the abstract class or implements the interface. So the factory will not 'shoot abstract enemy ships' but concrete ships that will be treated as abstract... I know that it "shoots abstract" but using the concrete... For me it was very difficult to understand that in the "pseudo UML" image, because it is linear, I think.
Had to repeat 2 times, but you are great at these! Keep up the good work,
Toughest one ever. You nailed it
It just seems so complicated. I guess for now I'm happy to know that this is possible and I'll watch it again if I find myself needing this. But great job anyway :)
Thank you :) Yes learning Design Patterns and Refactoring is pretty high end programming. Very often the most important part about learning them is to learn when not to use them.
I just made every pattern in the gof book. I tried to create them so that they could be used as self contained videos and didn't require the viewer to watch all of the others. The factory patterns seem to confuse people the most
Thank you :) I put everything on my website. What benefit would there be in putting them on GitHub? The way it is set up now, people can access the code and the video on the same page
Derek, I loved your channel. Thanks for all the effort you've put in to put together all these awesome videos. :)
Best of all among this playlist. Thanks a lot!
Thank you :)
I like your design pattern tutorial videos. They really help me a lot! Thank you very much!
+HE WANG You're very welcom e:)
I'm just trying to demonstrate the pattern while trying to keep everything as easy to understand as possible. At the end of my refactoring tutorial I provide another better version of this pattern
It is another layer of abstraction that is commonly used. The design patterns can come in different forms though. This is an example of the GOF pattern. I provide another example on the Abstract Factory at the end of my refactoring tutorial (Last Video). It may help to see it in a few ways