 Okay, the last pattern we're going into is the so-called factory or factory method pattern There's also based on this idea. There's another pattern called the the abstract factory pattern That's an extension to it, but we don't cover it here So the idea is that you have some kind of functionality In the creator here, you have some operation that does something that depends on a product and this product has a certain Signature it has methods for example here. I just called it do something And you want to decouple this creator from a concrete product Just to give an example because this is fairly abstract You might have very common and in again extensible IDEs like eclipse. You might have an editor And in that editor you edit certain resources and the basic case would be just for example a text file You have an editor that can edit text files So obviously that editor deals with a concrete product and that's a text file It has a certain format But now if you want to implement operations for example undo and redo this might Depend on what concretely you're working with so for a text file You might have one implementation if you instead are working on a model for instance a graphical model the undo and redo functionality might be different So you don't want to implement your editor in a way that it only works for one specific case But you wanted to make it general so that you can extend the development environment with different editors For example, if you come up with a new programming language or a new model format or something like that And the idea is that instead of in this operation just call the constructor and say I want to have a new product a or a concrete product a Instead of that you call this create product method. So you say, okay, my product is create Product and then you get some kind of instance of a product and you can call your do something method So you can say my product Dot do something for example undo please and Then the concrete behavior of how this really behaves and what is happening depends on the Realizations and implementations here. So You subclass the concrete creator for example for my file my text file editor And you implement the create method to create a concrete product of type a create a concrete file text file and then That concrete product has the implementation the undo and redo implementation for a text file And you don't really change this operation here It just looks exactly the same you create a product and you do something but you override just to create method itself That's the factory method So the creation is basically outsourced to the subclass the operation itself remains the same and by Dynamic polymorphism you basically You are using that while this do something method will just be different depending on the implementation So if you have another concrete product here Concrete product B That's for example our model file that one will have a different Implementation of the undo and redo functionality concretely for that and then of course for that we need a concrete Creator that can actually Deal with model files. So that one should then be aware that there is this Concrete product B. So basically we decouple the instantiation the creation of Objects to the subclasses so they can make it specific to the case And that's of course again a case of open closed that we say this is close to modifications We keep it very general and then the subclasses extended That's essentially what's at play here list of substitution as well Replacing it with any kind of subtype remains the same behavior. We have the same operation, but the polymorphism Leads to different implementations depending on the product Okay, this concludes the Run through our design patterns will now have a last video on which we summarize a bit what the issues with these design patterns are and Then we conclude the module