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
+Danish Khan, not everybody brain works the same. If so there will be no economic inequality in this world. There would not be wars. I am really shocked to see your comment here. A person who understand design patterns cannot understand brain patterns. :)
+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?
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
I actually have 2 design pattern tutorials. This one and another titled refactoring which is packed with patterns among other things. Stick with it and you'll get them. Make sure you completely understand OOP and design patterns will make a great deal more sense. I wish you the best and feel free to ask questions
I provide heavily commented code in the description. I also revisit this pattern in the last video in my refactoring tutorials playlist. I hope that helps :)
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.
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
I'm going to be covering UML next. Then I'll review everything in a very non language centric way. Then I'll make a c / c++ tutorial when I get into graphics because Java doesn't provide the speed I need to make games. So, Yes :)
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.
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.
If I ever say stuff that you don't understand I feel that I've failed as a teacher :( Feel free to point out what I can explain further. It will help me improve as well as those who are having the same problems as you that aren't speaking up. I'll do better to improve. Thanks a bunch :)
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'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
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
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.
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!
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
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 :)
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.
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 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
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
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
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?
+billyblackburn87 Really its easy. Think: Do you need to create a xThing or xAnotherThing? Make a xFactory, it would know how to create xThing or xAnotherThing or in the future xModernThing... Usually creating objects need lot of parameters and could get messy when you only want to say something like getANewXModernThing().... And then you allow to get a newThing or a recycledThing or whatever....
I'll gladly make another video to explain it further. I know this is a bit more complicated than my normal stuff. If you keep at it though you'll take your skills to the next level :)
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
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! :-)
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.
This might not have been the perfect example on using this pattern, but I was trying to keep everything as simple as possible. Later in my refactoring tutorial I get into more advanced better examples. Sorry about that
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.
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 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.
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.
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!
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
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!
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.
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!
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!
I **JUST** realized that this system is **probably** a good example how the Borderlands franchise implements their gun customization/randomization system at a very high level.
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.
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 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.
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.
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.
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.
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'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
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 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!
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 😂
What would the benefit of passing in the factory to the object actually be? The only thing I can think of is if you don't have access to the code of the constructed object.
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
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
Does every EnemyShip subclass need its own factory? I can't see the purpose of spiting up the construction of the ships into an EnemyShip subclass and an EnemyShipFactory subclass, if they're always unique then why not bake them into one? What extra flexibility does it add? The UFOBossEnemyShip and UFOEnemyShip classes are exactly the same, that seems strange and inefficient. Why even use subclasses of EnemyShip at all then? Why can't it all be baked into the EnemyShip class if the factories are the only thing that gives the ships functionality? Edit: Another thing is the EnemyShipBuilding and UFOEnemyShipBuilding, why split them up in in two? Are you suppose to make different Buildings for different lists of ships so that the "if" statements don't become too long?
+serock3 There's a similar example in Head First design patterns (you should read it). However, they use Pizza's and Pizza factories. It makes sense to have have abstract factory classes since you may have lots of different types of ships or Pizzas. Essentially the concrete factories make the ingredients and the concrete products (Ships or Pizzas) are composed of those ingredients. The beauty here is that the concrete products don't know and don't care how the ingredients are made, that complexity is moved away from them through the use of the factory. I suggest you look up "Program to an interface and not to an implementation".
If you wanted to make either a RocketEnemyShip would you have another abstract method in "EnemyShipBuilding" for the rocket ie. protected abstract EnemyShip makeEnemyRocketShip(String typeOfShip); If not, how would you distinguish between building a Rocket or a UFO?
Learn in One Videos for Every Programming Language
Subscribe to Bookmark them: bit.ly/2FWQZTx
C++ : th-cam.com/video/Rub-JsjMhWY/w-d-xo.html
Python : th-cam.com/video/N4mEzFDjqtA/w-d-xo.html
Java : th-cam.com/video/n-xAqcBCws4/w-d-xo.html
PHP : th-cam.com/video/7TF00hJI78Y/w-d-xo.html
MySQL : th-cam.com/video/yPu6qV5byu4/w-d-xo.html
JavaScript : th-cam.com/video/fju9ii8YsGs/w-d-xo.html
C# : th-cam.com/video/lisiwUZJXqQ/w-d-xo.html
HTML5 : th-cam.com/video/kDyJN7qQETA/w-d-xo.html
CSS3 : th-cam.com/video/CUxH_rWSI1k/w-d-xo.html
JQuery : th-cam.com/video/BWXggB-T1jQ/w-d-xo.html
TypeScript : th-cam.com/video/-PR_XqW9JJU/w-d-xo.html
ECMAScript : th-cam.com/video/Jakoi0G8lBg/w-d-xo.html
Swift : th-cam.com/video/dKaojOZ-az8/w-d-xo.html
R : th-cam.com/video/s3FozVfd7q4/w-d-xo.html
Haskell : th-cam.com/video/02_H3LjqMr8/w-d-xo.html
Handlebars : th-cam.com/video/4HuAnM6b2d8/w-d-xo.html
Bootstrap : th-cam.com/video/gqOEoUR5RHg/w-d-xo.html
Rust : th-cam.com/video/U1EFgCNLDB8/w-d-xo.html
Matlab : th-cam.com/video/NSSTkkKRabI/w-d-xo.html
Arduino : th-cam.com/video/QO_Jlz1qpDw/w-d-xo.html
Crystal : th-cam.com/video/DxFP-Wjqtsc/w-d-xo.html
Emacs : th-cam.com/video/Iagbv974GlQ/w-d-xo.html
Clojure : th-cam.com/video/ciGyHkDuPAE/w-d-xo.html
Shell : th-cam.com/video/hwrnmQumtPw/w-d-xo.html
Perl : th-cam.com/video/WEghIXs8F6c/w-d-xo.html
Perl6 : th-cam.com/video/l0zPwhgWTgM/w-d-xo.html
Elixir : th-cam.com/video/pBNOavRoNL0/w-d-xo.html
D : th-cam.com/video/rwZFTnf9bDU/w-d-xo.html
Fortran : th-cam.com/video/__2UgFNYgf8/w-d-xo.html
LaTeX : th-cam.com/video/VhmkLrOjLsw/w-d-xo.html
F# : th-cam.com/video/c7eNDJN758U/w-d-xo.html
Kotlin : th-cam.com/video/H_oGi8uuDpA/w-d-xo.html
Erlang : th-cam.com/video/IEhwc2q1zG4/w-d-xo.html
Groovy : th-cam.com/video/B98jc8hdu9g/w-d-xo.html
Scala : th-cam.com/video/DzFt0YkZo8M/w-d-xo.html
Lua : th-cam.com/video/iMacxZQMPXs/w-d-xo.html
Ruby : th-cam.com/video/Dji9ALCgfpM/w-d-xo.html
Go : th-cam.com/video/CF9S4QZuV30/w-d-xo.html
Objective C : th-cam.com/video/5esQqZIJ83g/w-d-xo.html
Prolog : th-cam.com/video/SykxWpFwMGs/w-d-xo.html
LISP : th-cam.com/video/ymSq4wHrqyU/w-d-xo.html
Express : th-cam.com/video/xDCKcNBFsuI/w-d-xo.html
Jade : th-cam.com/video/l5AXcXAP4r8/w-d-xo.html
Sass : th-cam.com/video/wz3kElLbEHE/w-d-xo.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.
+Danish Khan, not everybody brain works the same. If so there will be no economic inequality in this world. There would not be wars. I am really shocked to see your comment here.
A person who understand design patterns cannot understand brain patterns. :)
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?
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
Many more patterns are coming. New patterns and refactoring will be a major part of my next month of videos. Don't worry I'll cover everything :)
this is so deep in layers of abstraction that I can almost see Adele rolling in it
I actually have 2 design pattern tutorials. This one and another titled refactoring which is packed with patterns among other things. Stick with it and you'll get them. Make sure you completely understand OOP and design patterns will make a great deal more sense. I wish you the best and feel free to ask questions
I provide heavily commented code in the description. I also revisit this pattern in the last video in my refactoring tutorials playlist. I hope that helps :)
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!
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
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
I'm going to be covering UML next. Then I'll review everything in a very non language centric way. Then I'll make a c / c++ tutorial when I get into graphics because Java doesn't provide the speed I need to make games. So, Yes :)
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.
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
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
If I ever say stuff that you don't understand I feel that I've failed as a teacher :( Feel free to point out what I can explain further. It will help me improve as well as those who are having the same problems as you that aren't speaking up. I'll do better to improve. Thanks a bunch :)
You are very welcome :) I'm extremely happy that you found the videos useful
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'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
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.
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
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
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
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 :)
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.
Always feel free to ask questions. I'm here to help the best I can. Thanks :)
Thank you :) I'm very happy that I seem to be helping people with this topic
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.
"Well hello internet!"
Greatest intro on the internet
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 :)
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 :)
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
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 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.
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.
you should have included uml diagram
:(
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
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
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 :)
I hate this pattern
+billyblackburn87 Really its easy. Think: Do you need to create a xThing or xAnotherThing? Make a xFactory, it would know how to create xThing or xAnotherThing or in the future xModernThing...
Usually creating objects need lot of parameters and could get messy when you only want to say something like getANewXModernThing().... And then you allow to get a newThing or a recycledThing or whatever....
You just described the tip of the iceberg, there's much more to it..
sean0milan0 Please. Describe. I would be very gratefull if you do that :)
I'll gladly make another video to explain it further. I know this is a bit more complicated than my normal stuff. If you keep at it though you'll take your skills to the next level :)
I got it all loaded into Eclipse it makes it easier to follow what you did, wow 15 classes.
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
2022 and this is still relevant. Thanks man
Thank you for taking the time to tell me I helped :) I appreciate it!
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.
I think I improved on this video in the final part if my refactoring tutorial. I hope it helps :)
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.
You are very welcome :) Thank you very much for the kind message. I'm happy to help
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 :)
You're very welcome :) EnemyShipBuilding just provides a utility use and separates the code in to smaller pieces
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.
This might not have been the perfect example on using this pattern, but I was trying to keep everything as simple as possible. Later in my refactoring tutorial I get into more advanced better examples. Sorry about that
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
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
Thank you :) It is very exciting to be able to help people all over the world!
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
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 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.
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.
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!
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
You're very welcome :) I'm glad you found it useful
Yes you are very intelligent :) You definitely are getting the idea. All of your comments have been very insightful
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
You're very welcome :) I'm glad you liked it
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!
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.
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 :) I think I improved on this tutorial in the final part of my refactoring tutorial. Sorry about the confusion
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
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!
I **JUST** realized that this system is **probably** a good example how the Borderlands franchise implements their gun customization/randomization system at a very high level.
Thank you very much :) Yes I wish I would have made more examples. I plan on revisiting design patterns when I cover C++
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.
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 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!
You're very welcome :) I'm happy I was able to help!
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.
Thank you :) I'm doing my best to make design patterns understandable
Abstract factory is just a factory that creates factories
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.
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
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.
That is right. It just contains many factories that make different dynamic objects
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'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
What a great presentation of design patterns - demystifying...... Great job
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 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 :)
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 😂
All credit goes to seniors like you !!! :-)
What would the benefit of passing in the factory to the object actually be? The only thing I can think of is if you don't have access to the code of the constructed object.
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
Had to repeat 2 times, but you are great at these! Keep up the good work,
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
Does every EnemyShip subclass need its own factory? I can't see the purpose of spiting up the construction of the ships into an EnemyShip subclass and an EnemyShipFactory subclass, if they're always unique then why not bake them into one? What extra flexibility does it add? The UFOBossEnemyShip and UFOEnemyShip classes are exactly the same, that seems strange and inefficient. Why even use subclasses of EnemyShip at all then? Why can't it all be baked into the EnemyShip class if the factories are the only thing that gives the ships functionality?
Edit: Another thing is the EnemyShipBuilding and UFOEnemyShipBuilding, why split them up in in two? Are you suppose to make different Buildings for different lists of ships so that the "if" statements don't become too long?
+serock3 There's a similar example in Head First design patterns (you should read it). However, they use Pizza's and Pizza factories. It makes sense to have have abstract factory classes since you may have lots of different types of ships or Pizzas. Essentially the concrete factories make the ingredients and the concrete products (Ships or Pizzas) are composed of those ingredients. The beauty here is that the concrete products don't know and don't care how the ingredients are made, that complexity is moved away from them through the use of the factory. I suggest you look up "Program to an interface and not to an implementation".
I do my best. I'm very happy it helped you :)
If you wanted to make either a RocketEnemyShip would you have another abstract method in "EnemyShipBuilding" for the rocket ie.
protected abstract EnemyShip makeEnemyRocketShip(String typeOfShip);
If not, how would you distinguish between building a Rocket or a UFO?