Welcome everyone. Welcome everyone to this session of learn, design, pattern and architecture pattern step by step with the project. And this complete series, we're going to go and complete in eight hours, so in eight hours, we'll be completing most of the important patterns and architecture pattern in this project in which we are going to just stop. Now, the first question which will probably come into your mind is that is it really possible to cover all the design pattern in eight hours and that also in a single project? And that also with architecture bottom? My answer is no, no, not at all. But in this project, you know, we will be covering almost 60 percent of the gang of four design patterns, plus some other patterns which are other than Gang of four. As well as we will be covering at least 30 to 50 percent of the architecture patents. So yes, it is not possible to cover all the patents in a project, you know, because design patents cannot be forcibly used in a project, right? But I can tell you that in whatever project you are working at this moment, at least 20 to 30 percent design patents are already available. So why are this project my goal is to give you actual idea of how design, pattern and architectural patterns are used in a project. But in case you are concerned saying that, no, I want to learn all the design patterns and the rules, I want to go step-by-step. What you can do is you can follow our video series in which we have one question we did not come innovative. You have explained 40 to 50 design patterns, so you can see a factory about an abstract factory builder, prototype adaptor, decorator name that pattern, and it has been completed in this series, right? Now that there are two ways of learning design patterns. One is if you if you are a person who wants to go on a concept called barcode, then here it is. You can see that log into your question with the account and see this section step by step. Like this and the other ways by doing a project, take up a project, start coding and let the design patterns fall naturally along the way. But now, if you are asking me the suggestion, if you're asking me saying that. Tell us so what is good? Is going gold, but gold and platinum, the pattern is good. Are the project based approaches, but my personal choices is the project based approach. So started the project based approach, but as I've told that, I can complete 60 to 70 percent design pattern. The remaining 30 percent are still left out right. So those 30 percent design pattern you can go and watch from here. And second, what I'll be doing, you know, when I'm teaching you this project, I will be telling you to go and see more about the design pattern in this section. So I'll be guiding you at right places to hop to the series and then come back in the project. So my advice would be to go. While the project based approach and not why design pattern of the design pattern approach, I'll tell you why. Design patterns of thought processes and thought processes cannot be explained why the sample code or properties of some UML diagrams, if you see on the internet, a lot of people explain design patterns by showing UML diagrams, by showing examples like gods and trees and rivers, which does not make any sense. We need to do a real project. We need to fill design patterns. We need to understand that that in in what kind of scenario it has to be used. So the best way to learn design pattern is by doing a project. So I would suggest that you follow this video series and as time comes, I will tell you to go and see the appropriate design patterns on this section of light. Now, before I move ahead, let us, you know, just talk about one myth in which people have about design patterns. A lot of people think that, you know, in order to do a good architecture or create a good architecture, we need to implement all design patterns in the project. Also, I have seen that some of the developers tried to force design patterns. They say, Oh, come on, let's implement factory button. Oh, come on, let's go ahead and implement singleton pattern. But the fact is. Batons come out naturally. They are completely on demand as part of the scenario. So it is a very horrible myth that you need to force design pattern all you need to implement design patterns forcibly in your project or implement all these end patterns in a project. But the fact is that patterns are natural and they should come on demand. Now before we move ahead. And we start defining design patterns, we start looking at the project. Let me spend two or three minutes here discussing about. Difference between design pattern. Architecture pattern and architecture style. Believe me, guys, I worked with so many developers. Across different hours of the location, but different culture. But when it comes about differentiating between these three things, people just use these words interchangeably. So these three things, they must be looking very similar for you, but they have a huge difference between them. When you say design pattern. Design pattern is actually at the code level, so when someone says, OK, this is a factory design pattern, he should actually show you some kind of a sort of code. He should show you some kind of a logic. When you say it's the architecture pattern, then it's funny blog level diagrams. Example model view controller is architecture pattern that we see. OK, that is a controller. Then there is a model, then there is a view. The first tweet comes to the controller and then it picks up the model and the view. So over that we just draw. Blob, Douglas. It's a 30000 feet level view of your project. And then we talk about architecture style. They are just principles. They are just one liners, for example. The rest is the architecture style, which follows a study protocol. So remember design pattern. It is at the code level and the sort of code level somebody has to give you some kind of a sort of code. Then it becomes a design pattern architecture pattern just overall blocks like, as I've said, you know, model, view, view model or UI layer and then model layer and then the Audit Act closely. Now in all these layers, how they are implemented, what code goes into that that is not shown yet. An architecture principles. It is just principles, just one liners in which we need to follow. Know how do you follow it by using C-sharp or Java or whatever it is all up to you? So design pattern at the very code level architecture pattern, you know, it's multiple 30000 feet level and an architecture style, which is just principal. So next time you know when you see that, OK, this is a design pattern, I expect code from you next time and to say, OK, this is architecture pattern. I expect some kind of a high level diagram from you, right? And here are some examples of design, pattern, architecture, pattern and architectural style. So architecture patterns, anomaly or gang of four pattern like factory patterns, singleton pattern architecture, pattern of more block level you know, it seems like a model view controller, model, view, view model, model, view presenter and architect of style is the style. You know, it's just one line as it does principles. So, for example, the rest is architect and style, which gives importance to Entity B and also we have rest, we have way, we have AOC. So these are principles. These are architectural state. So before we move ahead with the project. Let us go and define design pattern. If you see the official design pattern definition on the web, if you go and search design pattern definition. Bet you'll find his definition, seeing that design patterns are time tested, solutions for software architects of problems. Again, I repeat, you know, most of the times, you know, this is a definition what is going on on the internet design patterns are Time-Tested solution thought software architecture problems. But believe me, guys. After working. 15, 20 years in IT industry and after doing a lot of designing and architecting. It came to one conclusion that design pattern is nothing, but it is objectively programming principles. It helps you to understand object to programming problems easily. So let me put on an unofficial definition ahead must be because of my experience and putting this definition. Design patterns are nothing, but they are best practices or Time-Tested practices for object oriented programming problems. And when you are doing design patterns, you know, you will suddenly feel that, OK, this is polymorphism, so this is polymorphism plus inheritance or this looks to be encapsulation. So, you know, as you do pattern after pattern, one moment of time, you'll realize that it is nothing but interfaces like classes, inheritance polymorphism and. So yes. Design patterns, then you start doing practically it is nothing but solving object programming problems in a much better manner. And in case you are too worried about this definition, what I've given because definitely I'm not the official person to define definitions here. But, you know, people who actually created Gang of Four, even they have admitted in their interview. And if you go and see this small interview in Nevada, you know, one of the persons from Gang of Four that is Mr. Gama when he was interviewed by Bill, you know, he said that patterns as a whole can help people learn object oriented thinking. It can help you to leverage polymorphism, you know, help you to design competition delegations help you to make a more pluggable system. So it is not just my feeling, my understanding here, but it also comes from the main source. You know, they also admit that yes, it is nothing, but it helps you to think of Uganda programming problems in a much better manner. So without wasting time, let us go ahead and discuss about the project. So this project is extremely simple project and in order to make the learnings easy and do not complicate things on the first goal, what I've done is that I have divided this project into various phases. So at this moment, we will concentrate just on phase one in phase one and we have just six to seven requirements. OK. So let us concentrate on the requirements and let us try to architect this system and let us see what design pattern comes up. So what is this? This crucial project this Culshaw project is, is a is a small software which a company wants to make. This company is a large retail shopping mall, and it has chain malls in Mumbai and Poonia City, and the company wants a very, very simple customer management system for their shops. And it has the following requirements in they want to fulfill. So first requirement number one application would be capturing three fees customer name the name of the customer phone number bill amount. You know how much is the build build eight and the address of the customer? So five fields, you know this application should captured in phase one. The second requirement is in phase one. There are two types of. Customers in which they have included. OK, so one is a lead, a lead is a person who comes to the shop, but he does not buy anything. He just inquires and a customer is the person who actually comes and buys things and does a financial transaction. So requirement number two, the system at this moment in, I should support two types of customers. One is the lead and the other is the customer. Now. The customer and lead have different types of validation that differ in terms of validation. Now a lead who comes to the shop, you know, he does not buy anything right. So for him, bill amount and build it is not compulsory. But yes, at least he has to give his name and phone numbers for that tomorrow. Probably my marketing people can call him up and say that, you know, there is a discount on something. So then it is a lead only customer name and phone number is compulsory, but for customer, all the fields are compulsory and the system should have a provision to add new validations. Rule seamlessly, right? Seamlessly, this is very important. So in other words, you know, tomorrow if I say, OK, now I want to go and add a new customer type as gold customer in offering these. This validation rules are true. So systems should be flexible enough not to add this new moon without doing a lot of changes across the system. That is a third requirement. The third requirement is systems. You should have the ability to add, update and delete customer data. The fifth requirement, which is again, a very important requirement. For now, the system will use a sequence of it and to connect to a sequence where it will use ADR dotNet as a data technology. But tomorrow the system would probably use new data access technologies like Entity Framework or Link You. So this migration from one data layer to other data layer should also happen seamlessly. You know, we don't have to do a lot of changes across the system. So that is requirement number five. And the last requirement is systems should have an ability of cancelling a modification. So if a customer, if the end user is going and and editing a record here, right, so there are some issues with the updated values, you know, he should have the ability to cancel. So this project basically has six requirements. First, there are five fields. Second one, there are two types of customers at this moment. They are having different, different validations. And tomorrow we should be able to plug in new customers customer type into this. It should have the basic cool functionality. And the fifth point is that basically we should be able to migrate from one data access layer technology to other data access layer technologies seamlessly. So this is the phase one requirement of this project. And in case you know, it is not clear from the video this requirement, you can go ahead and you can download this requirement from question. We did dot com. It's a very simple one pager word document innovative. You put this requirement so you can read through this because the other part of the whole video will revolve around this project. So this project is not understood, then you won't love the for the glasses, right? So it's important that you understand this project. Read it once and twice, and then continue with the video. So let us move ahead first and get a first try to identify classes. Let us identify our entities. And then, as we do the project to leg design patterns come in when it has to come. So first thing is to identify entities. Now, what exactly are entities entities are not anybody know they are things what you see in the real world. For example, a person is an entity, a living object is an entity, Siddhi. So these things are actually entities entities. In technical world or in object, the programming will be also done. Them as objects in shot entities are nothing but nouns. A good architect when he reads a igualmente. One of the things you know, which keeps going at his backhand is that whatever are the nouns, you know, they become classes and entities so he can see, you know, from our culture project at this moment, Mumbai puny lead customer, you know, these are some of the nouns I have identified. Remember that this approach has to be taken very, very wisely. You can come up with a lot of unconcern nouns, you know, which has nothing to do with your software, for example. I can see that, you know, there are nouns like, you know, the cool shop or Mumbai and Puni, but they really don't have direct impact on my project must be they have some data which have been stored in my database, like a seed master or something, but they really don't have an impact as such on my code. But you can see, like now, customer and lead are definitely in know which I would be dealing with in my project, right? So from here, I'm dropping off two three nouns like Mumbai Junior School Shop, but he has these two nouns that is customary and lead are definitely very important for me. So the first thing is. To identify entities outside the force, identify the knowns. And this approach. Please do take a very carefully right so that you know you don't come up with unnecessary nouns, which you will try to create entities off. Now, these objects or these entities needs to have properties and methods to identify the properties, the way to go ahead is by identifying pronouns. Pronouns actually talk more about the known, for example, you can see we have customer names, so customer name actually talks more about the noun. We have customer address, you know, that talks more about the noun. So whatever talks more about the noun becomes properties and whatever actions these nouns are doing, for example, ordering a product or asking for a refund. Those becomes the methods of the objects or entities. So just I'm trying to lay down a rule here. Rule number one for architects, for people who are trying to become architects or people who are trying to learn design patterns, then it will take a requirement at the back and some that don't take it as a hard and fast rule, but that back in some that you should think about that your nouns actually become objects. Pronouns becomes the properties for that object and actions becomes or the verbs becomes the actions or the methods of the functions of that object. Now, in order that these entities, these objects become live into your computer. You need to write some kind of code for it. These gold or these logics, you write in something called us glasses, glasses are nothing but templates. So basically, you write your code into the glass and this glass is laying into your hard disk and then you need to instantiate this glass and then your entity comes into your room. So to insinuate this glass, you know, we need to use something called as a key. What I'm sure that a lot of people who have already done programming know they are aware of what I'm seeing. So basically, if you ask me, object to programming is a three step process. The first thing is you need to create the glass, write the code for it. Then you need to in some shade the glass and then you can go and start performing operations on that object or on that entity. Now, creation of objects goes through three phases. Okay, so when you see that you want to actually make an entity live inside your computer, you need to actually at least do these steps. At least the first thing is you need to go and write a class, you know, you need to go and write the logic for that entity. Second, you need to go and use the new keyword and instantiate that entity inside your computer. And the last one is, you know, you need to go and interact with those objects and achieve the necessary functionality. So any kind of object to programming problems or also design problems, which comes into the class creation process, which is more static in nature, comes or falls into structural design pattern category. So we have a structural design pattern category, which will address problems regarding class creation, inheritance and also those kind of structural issues. They will come into structural design category. Second one is object creation instance, insincere single object. So when you're using the new keyboard, you know any kind of problem associated with instantiation will come into creation or design correctly. And finally, no, any object starts running the use polymorphism and they do type casting and accept us on runtime if you have any kind of architectural problems. It will come into the behavioral category. So you can see, as I've said previously, also design pattern is nothing, but it is object to the program, so it solves problems that don't object to the programming. So we can see by this view here or by this image here, you can easily make out that design pattern will revolve around classes, objects and instantiation. So now that we have analyzed the requirement and when we read the requirement, they use the noun pronoun and the verb approach to to conclude entities. And we said that we have two types of entities. One is the customer and the other one is the lead. So let us go ahead and create a class library. And let us go ahead and try to create the business layer. Business layer means, you know, the library in which our in which our business logic be the site. So I would go here and create a class library ordeal. And let me name this project as a customer project. Phase one, OK, is a phase one of the project. Now this class library, which I've created at this moment, I would like to go and. Name this library as the library in Nevada, my business logic, we decide. So let me go and put a very nice namespace here. So rather than just putting customer projects is one I would like to name this namespace as my middle name. So a lot of people can see this is the million. Some people termed this as the domain layer. Some people termed this as a business layer, whatever you want to term this as. But this is the layer you know that your business logic media site. So as we said, we have two kinds of classes two classes. I'm sorry at this moment. One is the customer class and the other one is elite class, right? And if you remember we said that, you know, there are five properties which we had identified by using the pronoun approach. We said, you know that we need the customer name, we need the phone number, we need the amount, we need to build it, we need the address and so on. So you can see all of these five properties here and also in a for the lead. Also, we have the same kind of properties, right? We said that lead and customer are different types of customer. So the customer is actually the customer who actually buys it. While lead is a kind of customer, you know who actually just comes and inquires about it, but he actually does not do a transaction. Now I do understand that in a lot of people would be screaming over there saying that here you have duplicated all these properties. You need to move it to a common class and so on. Believe me, guys, I'm going to do that. But the best way to learn programming is, or the best way to learn architecting is by doing mistakes and then gradually improving on the top of it. Right? So let me commit these mistakes. Let me see that you know how I can improve on it in the later stages. And in that way, you can also see this architecture revolution. So we identified the entities by using the noun strategy. We identified the properties of the entities by using the pronounced ADG. We identified the actions, you know, by using the lobster energy. Now this time to identify the relationship between these entities. Now, primarily, there are two kinds of relationship between entities. One is is our relationship and the other one is a using relationship or has other relationship. For example, you can see on your video that. Shiv is our son off his father, so it is more of a parent child relationship. She uses a card, or Shiv has. Oh, sure, it is more of a using relationship. Now if you look at the requirement and the requirement, it is clearly said that lead is a type of customer with less validations. I would suggest you to go and read the requirement again. It clearly says that it is our type of customer. In other words, the lead and the customer is having a kind of a parent child relationship. Probably both of these guys, you know, can be inherited from a common class. So let us go ahead and create a common class here, so I would go and create a common glossier class customer base, right? So this is a base class. It's a class, you know, which will have all of these properties over here, right? And what these classes that is, the customer class will inherit from the customer base, as well as the lead class will inherit from the customer base. So both of them will actually inherit from the customer base class. And also, we had one requirement regarding validation, right? We said that when it is only a lead, then only customer name and phone number is compulsory. But for a customer, all the fields are compulsory. So that means, you know, the difference between the customer and the lead is in terms of validation. Right. So what I do is in the customer base, let me go here and define a method, you saying. Validate. Right. So this method will help to validate a customer. But, you know, this method would be overridden by the customer and the lead as part of that requirement, right? So what I'm going to do is I'm going to go and make this method as virtual. OK. So by defining a method as virtual. What happens is, you know, your child classes means, for example, you can see over here I have the customer class or the customer class can go and override the validate method. And he can put all the validations here, while the class will only go and validate for customer name and phone number. Right. And in the base class, because this a base class, what I will do is over here, I will just go and up to a new exception saying that it's not implemented right. In other words, you know, this will be implemented by the change classes. So in the customer, all the validations will happen. So in other words, here the customer name is compulsory, right? So if the customer name blend is equal to zero, then I will go. And. So one new exception saying the customer name is required. And in the same way, I put validations for all other fields as well. So you can see for number, it's compulsory bill amount is compulsory billed. It cannot exceed today's date, address is compulsory, etc. But for the lead one only the name and the phone number is compulsory. Right? So we can see now we have the customer and lead, which are actually concrete types and they are inheriting from the customer base and then they are overriding the validate method, you know, as per their requirements. As for that need. So now let us go ahead and create a user interface and in the user interface, let us go ahead and consume this business logic in what we have created, right? So this is actually our middle layer, so let me go and rename this. And also, I would like to mention here I am creating this project in Visual Studio 2010. Why am I creating in a backward volume so that, you know, people what it was in 2012, 2013 and 2015 almost be 2016 tomorrow? You can easily migrate to this project and see the goal. And also, I am trying to create a version which is five years back and so that you can just do one next, next bizarre and see this code on it multiple and rename this glacier to like custom 0.6 or something. Right? So let me go ahead here and add a new project. So let me add on Windows Phone here. So I'll say it then from customers, right? And that is a phone. Let me rename this phone to a nice name. So I actually am creating a Windows UI to consume this middle layer or are the domain objects what we have created? And this woman UI for me is irrelevant, actually, because I want to just ensure that my marine layer and my data access layer are properly reusable. Right? But I do need a UI to test your drive, so I'm taking the windfarm, but feel free to use other user interfaces like GIS for at the farm or must be console applications, etc. So I'll say that for them customers and on this farm, you know, you can see I've I've put all the necessary user interface, you know, which will help us to fill data into our domain object or into our customer class site. So here is my UI. So what I'm going to do is I'm going to go and consume this middle layer inside my UI of informed customer, so I'm going to go and consume. This marine layer inside my windfarm customary Earth and over here, I will say using live right? So now remember that we have two types of customers. One is the lead and one is a simple customer, right? So what I've done is in this UI, I have created a very simple combo box, so you can see that I have a simple dropdown I straddle and this dropdown helps me to select in a what kind of customer I want to use if I select lead and if I do validate, then accordingly, the lead validations will fail. And if I go and select customer, then customer validations will be fired, right? So what I'm going to do is I'll go back to my UI. So depending on situation, I will see your private customer. So I don't see why we go and create customer object. Or probably it will go and create a lead object, right? So. In this combo box selector change event, what I'll say here is if the customer typed or text which is selected, if it is customer, then please go ahead and create the object of the customer. Or else go ahead and clear the object of the need. Sweatshirt cost is a new customer or else go ahead and create the object of lead, right and in the validate button again, yellow. So depending on what is selected, I will either called or validate of the customer or I will either call the validate of the lead. Now that is one big problem the approach at this moment. Before I talk about the problem, let me talk about. What is a sign of a good software architecture? If you want to see, you know, or if you want to test, I will say that a software architecture is good or not, you should see that how the software architecture reacts, you know, when change just happens, whenever a change happens in the software. And if you are to change at 10 places, then there is a problem with the software architecture. If you see a moment tomorrow, if I go and add a new customer or type over here for, let's say, I go ahead and add a new customer class glass customer, then look at the places you know where I have to make changes. First thing change number one, I have to go and add that new type here in the form. Second, I need to go and add in my selected event. I need to go and add one more if condition. Then in the validate event, I need to add one more condition, so I have to make changes at three places. And please note, at this moment, this is all very, very simple form. If I have been such forms like this, you can think about that. You know what kind of changes can happen in my system? So a good software architecture is tested, you know, when the changes happen. And if you are changing in a lot of places, that means you have not architected your software well. So first thing is, you know, let us see that if we can minimize these changes from at least, you know, three to one. OK. So let us go step by step. So at least, you know, can you bring down these number of code changes, right? So the first thing what I can really do over here is I can use polymorphism. So in other words, if you remember both of your classes, that is customer and lead inherits from the customer base class. So what I can do is I can just go and create one reference for the whole UI, so I can say, OK. This is customer base, and depending on situation, the customer base can now point towards new customer, or he can point towards a lead, right? And then in the valley dead, I can just say good start, validate. So if you see now when I go and add a new type, right, I have to to go and change in this section. That's it. So we can see because of polymorphism, this is polymorphism, right? You know that in the patent, glass can point towards his child classes on runtime. What do you mean by polymorphism? Polymorphism means change as per situation. So he can see a, you know, my cost object is actually of customer base type, and depending on situations, it can point to customer or it can point to the lead object. Now, one of my personal belief is that. The biggest gift from IBM, the programming is polymorphism. If you see polymorphism in our real world also, you know, real life polymorphism means, you know, depending on situation, you change yourself. For example, at this moment I'm teaching you so I will not be talking about my family work. So I am a teacher at this moment, but the time I go and meet my kids, I play with them. I don't talk about my office work. So at that time, I am a dad and I just want to ensure that I don't talk any kind of official work. So in real life, also people achieve decoupling. Decoupling means, you know that no one what is happening in your office, you don't take it home or whatever is happening in your home. You don't take it office when you actually do polymorphism. And the same here in objecting to the role. Also, polymorphism is the biggest gift by which you can achieve decoupling right by by which you can ensure that change happens at one place. It does not get get, you know, does not go all over the place, right? So you can also, you know, by using polymorphism, you can see this woman. I'm using polymorphism. And because of that, I minimized my changes from three to one night. But Steve, I have to still make changes. In other words, if you see now and somebody goes and adds a new type, so the first thing is he has to go and add the gloss over here. After that, he has to again go back and add a new if condition. You're in this combo change and think about it, you know, if you have 10 schemes like that, then you have to go and do it, do it at 10 places, right? So somehow we have to also get rid of this if condition as well from this UI. Now, in order to remove this, if condition from here, what we really need to do is we need to get rid of this new keyboard. Remember, what is the whole goal? Of this exercise, we are trying to do removing if conditions or removing the strongly type plus the straight or concrete classes. The goal is that when I go and add a new customer type, I shouldn't be making changes here. So if I am, if I don't want to make changes in my UI, then I need to get rid of these final classes or concrete classes. Right? And in order to get rid of these classes, I need to somehow ensure that in know the creation of these objects, you know, goes into some central class. So in other words, I need to. Give this object creation to some other library. Right? So what I'm going to do is I'm going to go and add a new class here or a new library here who will take away this object creation process from here into that class library. Now I would have to go and name this class library as Factory Line Factory because it creates things, right? So I'm going to go here and add a new project. And I will say this project, Neymar's factory factory custom. And in this, let me go and create this glass as a static glass. So I will say this is my factory, right? So this factory glass will be responsible for my object creation. Right? So I would have one add a reference to the middle layer here. So now what I will do here is I will say. Public. Create right to create the customer, depending on the type of customer. Right. And what I will do is I will move this condition from here to this factory glass. So we're here now and say, OK, if. The type of customer is the type of customer customer, then return to a new customer orders return. A new lead. Right? So you can see now this glacier, this factory glacier is taking all the responsibilities of creating the object. So he's aware of all the strong type object, so in other words, the more if you add a new type, you just go and add one more if condition yet. But when he returns this strong type, he will always return it as the parent base class polymorphism. Remember, the base of decoupling is polymorphism, so you can see how to modify and add a new type. He will always go and return when the customer base. So my UI now can become something like this so I can see here. So my UI will now go and for the factory customer class or the library. So I will say you're using the customer and then in the customer type, in the customer, they'd selected event of the combo box. I can see say, please use the factory and create the object so you can see now in my UI, I have no preference of the customer class. You can see now on the lead class must begin to search for the lead. So we can see there is no reference of the strongly type Plus's, right? So you can see now by using this simple fact pattern, yet able to decouple the user interface from the strongly type classes of tomorrow. If somebody goes and adds a new customer type here, he has to just go and add that if condition here and that's it. And all other consumers, so it can be a UI, it can be a batch process, it can be anyone. They don't have to worry. You know what kind of tape is coming from the factory? The factory takes the responsibility of creating the object. Now, there is one serious problem with this factory class. And the problem is the if condition is I have to get rid of this if condition and we need some better approach here. Now the good news is if you have polymorphism in action, then you can get rid of these conditions. So if you have polymorphism and if you see lots of if conditions and case statements, that means polymorphism has not been exploited to the full. So what I can do is I can go and delete this completive condition and I can go and create a very simple collection here of customer base type so I can go and do something like this. I can go and create a collection based upon dictionary. The customer base is a go to new dictionary of customer base. And what I can do is in the in the constructor, I can go and add the newly the strong pipes or the concrete type so I can see it'll get this new customer. And this is for lead. Right. So now we can just go ahead and return the customer time by just doing a look up. So we don't need now that you've conditioned, so I can just see how that done costs. Now remember that this costs. The result is a non static variable rate. And inside the static methods, you can only access static variables. So we need to make it static. So that's a cost of type gust and hit it on some type. I can see we don't need any more this condition. It can be just removed by symbol lookup and the look of bill work. Why? Because, you know, polymorphism is happening internally. So basically, people don't look up. It will give that customer, but that will get automatically tied to a customer base, right? So we're here now again, if you see. It's the same kind of output. There are some errors. Let's see what else are there. Let me go and first rebuild the solution. Let us see what else we have. Starting classes cannot have instant constructors, so that is right. So basically, this has to be static, right? So let me do a rebuild now gain. And let me do a fly, so now if I do a lead, it goes it looks up to the election and gives me back a lead pipe. If I do look up of a customer. So there is a customer who again doesn't look up, it goes, looks up, and it gives me a customer type so it can see now. We have a factory glass centralised on the new Newquay was all centralised there. And also, we successfully got rid of that if condition this getting rid of this condition by using polymorphism is doomed as the RIP Patton RIP means replace if that polymorphism. This centralisation of object creation is doomed as factory batten. But remember that there are two kinds of factory button. One is what is discussed by a gang of four, and this one here is a simple factory button. So this factory is doomed as a simple factory by them. So what they'll do is, you know, all over the project, I will just put this word design pattern right, and I will put the name of the button design pattern and name of the patterns so that the model, if you were to just go and see if you don't, if you just do a control shift I. And if you just search for a design pattern, you know you should be able to straightforward go and see the references. Right now, this factory glass can be improved in terms of performance. If you look at this moment, this customer collection is loaded irrespective you want it or you don't want it. I want that the customer types should be loaded, lonely on demand. So in other words, when somebody calls this create method at that time, the customer collection should be loaded. So what I'm going to do is I'm going to go and control this. I will remove this constructor and over here I will see if the costs don't count is equal to zero. Right? Then go and load the types. So you can see that when somebody calls the create method right at that time, one of the customer types are loaded or else, you know, they are not loaded, you know, without any reasons. Right? This pattern is doomed as lazy. Loading. So again, one more design pattern here. Lazy loading the opposite of lazy loading can be termed as eager loading. So lazy loading means, you know when the objects are needed, you know they are loaded or else you know they are not loaded. OK, so we can see three design patterns we have go at this moment factory button repairs. If the polymorphism and lazy loading pattern very quickly, I would like to make a statement here. One is, you know, design pattern. The other is you should know the automation for the design pattern. It is very important that if you have automation for the design pattern, you should be using that and not actually coding from scratch. So you can see, for example, for lazy loading in C-sharp know we have a quiver called as lazy. So rather than writing such kind of a if condition and then checking it and then loading it, you can just go and use that lazy keyboard. So I would I would give this you as a homework. You have a value in question, really, which talks about the lazy keyboard. So use that lazy keyboard and replace this if condition of the lazy loading pattern here. OK. So remember, one is you should know the pattern and the other is in case you know, there is some ready-made framework or some readymade component, try to use that component because components are time tested. You don't need to reinvent the view from scratch. So take this as a homework. Go ahead and replace this if condition of lazy design pattern by using the lazy keyword of shisha. Now, let us quickly go into sort application. So what I will do is in the validate. We are already getting the tape right. So let us create a medley of things, said customer. And so this method will set costs start. A customer name is a call to DSD, customer name, text go, start of phone number, the phone number or text. This matter here actually goes and takes a value from the UI and sets it to the object, right? So before I call the validity, I would like to just go and call this said customer here, right? And let us quickly go and test this. So basically, if he's a lead, then customer name is compulsory. OK, so if he's a lead, then customer name is compulsory. I doubt it is if I put the customer name, phone number is also compulsory, but the address is not compulsory, so it is working. But the time said this is a customer, right? Then even the bill amount is required. It cannot be zero one, the addresses required. So we can see now, you know, depending on what kind of by selecting your is calling, the factory factory gives him that type. And depending on the type, the validations are happening and and you can see. Clive, tomorrow, one at a new customer type, I don't have to make any change in the UI, in the UI. I just have to go and add that tape over here and when we have to change is in the factory glass. I need to go in the factory glass and just go ahead and add the new type into my collection here. Right? Well, this brings us. One hour of. Learn design patterns step by step. And in this one, I would believe me, guys, you have literally crossed the sea. Well, I'm not teaching a design pattern. Step by step. I'm not teaching you design by academically, I'm teaching a design pattern practical. So once you see these examples, you will never forget, you know, how to use design pattern in your project tomorrow. So basically first we started with design pattern. We define design pattern, and we said that design pattern is nothing but a learning object, the programming in a better way. So they are time tested solutions for object oriented programming problems. And then they said, you know, the design pattern falls into three categories. One is the structural category, you know, so at the time, then we build our classes and the later entities. So any kind of problems, you know, that occurs during that phase. Will be solved by using the structural design pattern category. And then they said, you know, there is a second category called Creation Button, which which actually revolves around a new keyboard. Then they said that there is something called a behavioral pattern, which actually talks about the problems that on dynamic nature of objects. So that, you know, we also defined what is the difference between design, pattern, architecture, pattern and architecture style. Then we moved ahead and we identified the entities and the objects and the classes by using the noun, noun and the verb approach. Identified the relationship between these entities, we said that there are two kinds of relationships. One is it is a relationship and one is it has a relationship. So one is using inheritance and the other is using, you know, aggregation association composition. So it is more of a using relationship. After that. He went ahead. And we created the UI to so the created the classes and properties, we created the UI. Then we said that we are having problems with the new customer types. So we said that if new customer types get added, then we have to make changes all over. So we went ahead and we created the Simple Factory class, the simple factory glass is nothing, but it actually collects all the new gear into a centralized location. Afterwards, we moved ahead, we said that, OK, this simple fact, the class is looking good, but we need to replace that if if condition it was that if it had, it had a if conditions and that if condition will increase, you know, as new types gets added. So they replaced the if fit polymorphism. That is a second pattern which we implemented. We toward you said, you know, how about improving the performance of this factory class rather than loading the objects? Always. How about loading them on demand? So we implemented the lazy design pattern. So we have more seven hours, depending. Let me talk about what I'm going to go on in the next coming hours. The next coming, our. I will be covering something called a strategy battle. Because if you look at this moment, the validations are completed tightly coupled with the entities. So we will look into that you how we use that to do better and improve on these validations. We will also see how we can go and automate the factory burden, plus the Simple Factory button plus, because at this moment, if you see, you know, we are writing a collection, then we are doing a look up and whatnot, right? But in reality, if you think about it, you know, if you want to go and create a lot of these factories like this, you end up into a lot of custom coding. So as I've said in this class, also one is, you know, the design pattern and other is, you know, how to automate that design pattern. So also what we'll do in the coming hours is we try to automate that factory class. We try to remove that collection. We will try to remove that look up, right? Third. We will also implement some simple patterns like GO, program pattern and Memento patterns. Again, the next coming out is more exciting. It is more adventurous, and we will be learning all of this design pattern practically and not just terrible. And again, don't forget in case you want to go and learn pattern by pattern. Is go ahead and see this video series in Nevada, we have explained pattern by pattern so we can dig up one pattern. We national a sample code for it. We can understand it. Then there is a second pattern thought pattern and so on. So if you want to learn pattern, the pattern will to the video series. If you want to really see patterns happening, then this is the video series which you have to go to. So thank you so much for getting me for one hour. And if you really like this series, then again, be ready for the next coming out as the latest. So seven hours, depending. And if you don't give up, then I will also not give up. OK. So if you have the zeal to learn design patterns actually and practically, then I have the zeal to teach you. And in case you like to see this in case like this one hour, what you have learned is go to Facebook dot com slash correspondences that will get completed one hours. I liked it and I'm waiting for the other cities. Audience, you know, in case if you have any issues and concerns, you can also raise those concerns on the Facebook page. Thank you so much. So let us complete the seven hours and let us become a real, real architect. And let us become a person who knows design pattern actually, and not just set out today. Thank you so much.