Strategy Design Pattern Explained with Real-World Example | Design Patterns in LLD

0:00 Yes sir, let's start. So, welcome back coder army. Today in our LLD series we are going to start design patterns. And in this video today, first of all we will see what is Strategy Design Pattern. First let us understand what are design patterns and why do we use them? And then we will move on to our design patterns. So let's imagine that whenever you develop some applications, you face some common problems. Right? But this problem might not be happening to you for the first time. There might be many developers who might have faced the same problem. So when they were going through this problem, they had already found out the solutions, like if this problem arises while making the application, then we have to follow this path and our work will be done. We use those solutions which they have already found for the problems.

0:47 Use their wisdom to solve the problem. And this is the essence of design patterns. What did people do? Whatever problems arose in designing an application, we created particular patterns for them, which we called design patterns. Now whenever we face that problem again, we use that pattern. Our work is done. Right? So as we discussed earlier, applications always keep evolving. The application will keep on changing. New features will always be coming and your application should be flexible enough that any new feature integrated into your application requires minimal code changes. Basically what we talk about is that to integrate any new feature there should be minimum code changes and minimum time and this is what we call a flexible design. And to use these designs, we

1:33 use features whether it is object oriented principles, solid design principles or these are design patterns. All these happen so that our designs can be better, flexible and more evolving. Right? So always remember this. No matter which coding language you use to solve problems, or which company you work in. Change is the only constant that you will see every time. Your application will keep changing and you must always design it in such a way that as your application changes, minimum code changes are required to integrate the new feature. Just remember this. Ok? So now we understand what are design patterns ? What does he want to say roughly? Look, we have lots of design patterns. Ok? There are officially 23 design patterns. But all the design patterns are saying the same thing in different ways. And the thing is that there will be

2:20 some part in your application which does not change, which will be the static part and there will be some part which changes, changes repeatedly, which is the dynamic part. So what you need to do is remove that part of your application which is changing repeatedly, extract it from the part that does not change and store it separately, keep it in separate classes. What will happen with this is that whenever your application changes, only that part will change which changes repeatedly and it will not affect the part which is not changing. Right? So what I mean to say is that every design pattern implements it in different way. Today we see what is Strategy Design Pattern? And how does it implement it. Come on, come to the screen quickly. So first thing we're going to look at today is the Strategy design pattern. Let us go. So first of all let us talk.

3:07 Let's suppose we are creating an application and what happens in that application is that we have to simulate robots. Ok? So basically there will be an application in which there will be many robots in different forms which will be visible and moving in that application. Right? So we just have to create a simulation of them. So this is our application. Come let's see it quickly. How can we make this happen? So as we talked about, we have to simulate robots. So what do you do first? Let's create our own robot class. Ok? This is our robot class. Now what are the features that we need to integrate into our robot class? Look, first of all we would say that walking is a feature. Every robot can walk. A talk is a feature. Right? And another feature is what each robot looks like? So its projection right?

3:52 This projection is an abstract method. Because every robot will look different, whichever robot inherits the part will create its own projection according to its own requirement. Ok? Till now we have kept only two main methods. A walk and a talk. Right? Now one thing before moving ahead, Strategy Design Pattern will prove in your mind that inheritance is not a very bad thing. You will say brother what is this? Inheritance is very good. Inheritance helps us to extend the features. Infact inheritance is a very important pillar of object oriented concepts. Right? You already know this. We also talked about it. What does inheritance do? Extends a child class from a parent class. So the child class has all the features that the parent has. Plus there may be some additional functionalities. But what the design pattern is saying here is that inheritance is a very useless thing. Why is it useless for you? When we will

4:39 solve this problem then you will understand why inheritance is useless and what we should do to solve it. So now let's move ahead one more time. I told you that we have a Robot class which has two methods. There is a walk , there is a talk and there is a projection. What does that robot look like? Whoever inherits the robot will create projections on his own side. But walking and talking will remain common. Good. So now let us tell you what its child classes can be. So till now only two types of robots exist in our applications. One is our companion robot from Let's. Right? I declare this by making it a companion. And one is our A Worker Robot from Let's. Ok? We can name anything. We have chosen this name for now. Worker robots. Ok? Now I said that

5:27 this companion robot is a worker robot because it is the child class of both of them, so it will just override the projection method and the rest will remain the same which is coming from above. Right? So these two child classes overrode the projection. Right? So till now our application looks like this and it looks really cute. We are not facing any problem with our application. But let's suppose now we have to integrate new features. Ok? Now some new types of robots are coming, one of which is called Sparrow Robot. Ok? So we said, okay, quickly as soon as a new robot comes, what do we do is we inherit it here and write the name of that robot here, let's name our Sparrow robot. So, Sparrow. Now the special thing about this robot is that it can walk and talk but it can also fly, it has fly behavior,

6:13 so we said, there is no problem because it has inheritance, the functionality of walking and talking is already coming to it from its parents. We just do one thing. Let's create a new method with the fly here and the projection will definitely happen. Right? Right? So here we have solved this problem. Now assume that many new types of robots are coming that can fly. So let's say Sparrow robot arrived today, or tomorrow a Crow robot from Lets arrived. The crow robot will also fly. He will also have his own fly method. Ok? While doing this, suppose many new types of robots are coming which can fly. So do you understand what the problem is? The problem is that the fly methods in these robots, this one fly, this one fly, all of them are the same. Ok? So what do we do? The code of that fly has to be copy-pasted again and again. So whatever

6:58 code of fly we would have written inside this method, the same code will be written inside this method. And we will write the same thing in different fly robots. Right? But this is breaking a very basic principle in making any design which is DRY principle. Dry Do Not Repeat Yourself. That whenever you are writing code, do not repeat yourself again and again. Do n't keep copying and pasting your code over and over again. Write it down somewhere once and use it again and again. Right? So that is absolutely correct. So what did we think? We thought let 's do one thing instead of writing fly here again and again. Let's put the fly directly in the parent class and create a method for the fly here and define it here. But this will cause a problem here because we have declared fly. So if we

7:43 call fly to any robot then all the robots will start flying. Be it a companion robot or a worker, these can certainly fly. Right? But this is a problematic matter. We don't want all the robots to fly. We just want these special kind of robots to fly. So what did we do? We used our object oriented concepts and said let's do one thing, let's increase the hierarchy of inheritance. So now our hierarchy looks something like this. So this is how our hierarchy looks now that we have a Robot class. For that we created a separate child class called Flyable which are the robots that can fly and the rest are Noberts called Non-Flyable which cannot fly. Coming inside Flyble we created Sparrow and Roo Crow. What special thing did we get from this? This means that now I can declare the fly method here. Ok? I can define sorry. So right now I have declared it here by mistake.

8:29 We will remove the declaration and define it here. So now there is no need for the fly method here. They will just have to create their own projection method. Right? Which is what everyone else is doing. This too will require its own projection method. Right? So how did this help us ? Now, whatever types of flying robots we will have, we will keep extending them from here. So what will happen with this? We don't have to write the fly method again and again. But you can understand this, right? What other problems are going to happen next? We are entering a slippery slope. This problem will occur again and again. For example, now I tell you that a new type of robot has come which can fly. So you will say that if it can fly then I will quickly put it here. Tell me brother how can it fly? I am saying that he can fly, but he does not fly like these people fly with their wings. He flies in a jet. So its name is a jet robot.

9:15 Ok? So here comes a jet robot from Let's. Now it can fly, but it flies via jet. So this cannot come inside Flyble. But what can you do, let's do one thing, keep it inside the fly ball but override the fly method in it, then instead of using this fly, it will use its own fly method, no problem, but now again the same problem, let's say many more robots like jet robots have come, for example, this was one, similarly a jet robot two came, a jet robot three came and all of them have the method of flying with the jet, so the fly method of all of them will again be the same here, here and here, the do not repeat principle will be broken again, so now what will we have to do? Our inheritance hierarchy will have to be increased again. So now our hierarchy will look like this. So this is our hierarchy. If we integrate another kind of

10:01 class in between which is fly with wings and fly with jet. So now there are two different types of flying behavior. A sparrow and crow are flying with wings. And jet robots are jet robots to fly with jet. So here we have handled it with the hierarchy. Now this problem will keep on increasing. It will keep increasing. Now more new types of robots are coming from Let's. I am saying that there are robots that cannot walk. So they have non walking behavior and due to lets they can't even fly. So he must be here somewhere. Right? And what will we do? After bringing them, we will override their walking method and write 'cannot walk' or something like that. But again let's say a lot of such robots come, then we will have to change the hierarchy again and our hierarchy will become complicated. Then there will be some different workables that can be operated. Those who are non-vocable will be separate.

10:47 Something similar will happen with Imagine Talk as well. There will be some robots which will be talkable. Some will be non-talkable. In that also vocable and non vocable can be different. Flyable and non-flyable may vary. So this hierarchy will become complicated. It will keep happening, it will keep happening. It will become very complicated. And it will look something like this. So see here, by applying all the permutations and combinations, we are complicating our entire inheritance hierarchy. Talkable Non Talkable. Now in tutalkable also fl workable non vocable. In this also, vocable and non-vocable sub-categories can have flyable, non-flyable and many types of permutation combinations. So you can understand what the problem is. With each new robot integrating each new feature, our inheritance tree becomes more and more complicated. Right? So this cannot be a solution. Ok? And anyway, this is a very famous line. The Solution

11:34 to Inheritance Is Not More Inheritance. Right? To solve inheritance, we cannot add more inheritance. So this is the problem. Now let us conclude what problems we faced due to inheritance. Ok? So we faced all these problems by using inheritance. We did n't get the cold reuse properly. Many changes were made to add new features and it broke the open-close principle of solid design. Right? So what is the solution now? Look, Strategy Design Pattern brings the solution to this. So let us first look at its definition and then see what it does? So by definition the Strategy design pattern defines a family of algorithms. Put them into separate classes so that they can be changed at run time. Now I don't think you have understood anything from this definition. So first let us integrate it in our robot example

12:19 and then we will again go towards the definition and then maybe you will understand the whole definition better. Let's recreate our entire robot class once again. So this is our robot class. In this class, I have written all the methods we have in one class. Talk, Walk, Fly and Projection. No I haven't created the child class yet. So let's review what our definition of design patterns was saying. I said that broadly speaking design patterns tell you that some part of your code will change again and again and some will not. So whatever change happens, we should always separate it. With that which will not change. So, which methods do you think were causing the problem in this class ? Look, there was trouble because of talk, walk and fly. Because they are bringing complete changes and new features that can walk in a different way, walk and talk in a different way

13:04 and fly in a different way. But the projection would always remain the same because each robot would look unique. Right? So that will always override the projection method. Other things were changing again and again. So what should we do? We should remove don't talk, walk and fly from this robot class. And, after taking it out, only that should be allowed to remain in the robot which will not change. Which is projection? Right? Once we have done this, we will have completed half of the definition, which is it define a family of algorithms. Now this talk, walk and fly are also algorithms. Right? Because what is an algorithm? The algorithm can be anything. Whether it is a method or a complete concept, it is an algorithm. So according to this definition, our three – talk, work and fly – are algorithms. You

13:50 define some family of algorithms and we put them in separate classes so that they can be changed at run time. Now let us see what this means? So first of all, let us take these out. Let us do one thing. We remove this talk, walk and fly method. Now what does it mean to be thrown out? Here we wrote fly from talk, walk and let. Ok? But how will we take it out and use it? So we make separate classes for all of them. And by classes I mean interfaces. We put these in abstract classes. In which only these methods will be there. And we will use these classes in robot classes. see how. So, what did we do first? We built an interface from Let's Talkable. Ok? Now Java has an interface. There is no interface in C++. So in C++ we call it an abstract class. The

14:36 simple concept is the same. It is just used by different names. So we made the interface Talkable. In this we can put our own method of talk. So we started the talk. And because it is an abstract class. We have just declared the talk. And we write the abstract on it. And that's how we make it walkable and flyable. So we created all these interfaces. Now we've taken the Talk, Walk, and Fly out of the robot. So let us quickly delete it from here. And let's leave only one method in this which is projection. Right? Now the advantage we got from this was that firstly, we separated all the things that were changing. And now this thing which was not changing, we left it separately in the robot. Now I said that talkable, walkable and flyable are all interfaces.

15:23 These are all abstract classes which have one method each - talk, walk and fly. Now what will be its concrete implementations? So let's make it quickly. Now the concrete implementation is how many ways do we have to talk? Right? Like we made it above, one talks to the other like this, one doesn't talk. One flies from the jet's key, one flies from the wing. So these are all his ways of talking, flying or walking. So we create all these methods from concrete classes from abstract classes. So let's just create two types of concretions in all. Let's make one normal and let's make the other with no behavior. So like I said, one of ours will be normal talk and the other will be no talk. Look, not talking is also a kind of behavior. Right? Similarly, not being able to walk is also a kind of walking, and not being able to fly is also a kind of

16:10 flying. Remember this. Ok? So like we made no talk and talk. In both we have kept the talk method which will overcome it. Once this is done, we keep it from him. Talk method which will be overridden and similarly we quickly create all the child classes in Vocable and Flyover also. So here we have created all the child classes. Right? Made all the implementations. Now you must have understood what we have to do. All we need to do now is to have a has a relationship or a composition relationship in the Robot class. From Talkable, to Fly, and to Vocable. Now the advantage of this is that our Robot class is not using inheritance but is using composition to integrate the functionality of talk, walk and fly within itself. Now what shall we do? We will first

16:57 store the references to these three in the Robot class. Something like this. So we have references like Talkable, Walkable and Flyable which are pointing to this Talkable interface, Walkable and Flyable interface. Now, whatever type of talkable, vocable or flyable is passed in its constructor, whether it is normal talk or no talk, normal voc or no voc and the same normal fly or no fly, it will be executed by us. Ok? Because it has a relationship with these three interfaces. Right? Now in the terms of these strategy design patterns, this main class of ours which is using all these is called the client. Ok? Because the client is using these algorithms. And these different hierarchies that we have, hierarchies of different algorithms, we call these strategies. what do you say?

17:42 Strategies. Ok? So one is our talking strategy, one is our walking strategy and one is our flying strategy. Now the interesting thing is that now you do not need to draw many permutations and combinations. Now whenever you create a new type of robot , you can pass any kind of talkable, walkable or flyable thing into it. Now polymorphism will dynamically decide what kind of tok it is, what kind of wark it is and what kind of fly it is. And that robot will start showing the same behavior. Let's use it practically and see how? First of all, we first make a robot of some sort. We had two types of robots. Right? Companion and a worker robot. Right now we make only one. We declare only one companion robot. So this is our companion robot. Ok? Now this companion robot will have its own projection.

18:30 Right. Now when we define this companion robot in any of our code, we will be writing something like this. We might be writing, let's make a new robot. Let's call it Robot Equals to New. Now in NEW we create a companion robot. from lats. Ok? So we created a new kind of companion robot. So now to this companion class we will pass a reference of type TalkableVocable and Flyable. That which dynamically decides how things will work. In what way does it mean whether it will talk, walk or fly? Ok? So let's quickly pass the fly. So we will pass it like this. From Let's to Walkable we put together a new A Normal Walk Sorry Normal Talk. So he talks in a normal way. It became talkable. Now next is Workable. For walkable I wrote 'Let's say normal walk'. So the

19:16 object of the new normal walk is passed. And for Flyable it has non flying behavior as of late. The companion robot cannot fly. So new non flyable is okay? Now you might have understood what will be happening is that we will have a constructor in the Robot class. That constructor talk, walk and fly would declare that this type of talking, walking or flying is going to happen. And he'll have all these methods. Like we will have walk, we will have talk here and fly here. And what will these methods be? They would just be delegating their requests to these particular references. For example, whenever you call this walk, what will it do? w dot walk will make a call. So this will

20:03 call the walk method on the reference W of this interface workable interface. Now depending upon which work we have passed. Whether it is a normal walk or no walk, its walk method will be called. For example, for this robot, if we did W dot walk, then normal walk i.e. this method will be executed. Similarly, what will he do with his talk method? T dot talk will make a call. Now what talk was passed here? Normal talk means this method will be executed. Similarly, we will call f dot fly and if no fly is passed here, then the method with no fly will be executed. And by using all this polymorphism, we no longer need much permutations and combinations. We just create a new kind of robot. In that, we pass all three types of behaviour as a constructor and use their methods. Now this robot has become a kind of dump object. Or dumb object means it is not doing any work on its own.

20:48 He delegates all the work. Talking is done by the talking interface, walking is done by the walkable interface and flying is done by the flyable interface. So all this work is being delegated to other interfaces. Right? So this is now a dumb object and our whole Strategy design pattern ends here. Now if you understand this definition once again then you will understand correctly that it defines a family of algorithms. Here is the family of algorithms. Put them into separate classes which we have put Talkable, Walkable and Flyable. So that they can be changed at run time. Now we can change it at run time. Now we can pass any robot here. Instead of normal talk normal walk we can do no talk no walk. Flyable can make any change. So by creating any permutation combination, we can create a robot

21:35 which will use it and we have completely eliminated inheritance and replaced it with composition. So this is what Strategy Design Pattern also says. If you put it all in one line or conclude it in one line then it will say that favor composition over inheritance. Composition is always better than inheritance. Because inheritance brings the same problem that we saw above and composition solves that problem exactly. Now imagine you have to come up with a new kind of behavior, basically a new kind of flying behavior. So you don't have to do anything. Here we will have to create a child class. Let's say normal to normal fly no fly and you keep let's say a fly with jet. Okay, you have created a flying behavior. Similarly, if you want to create another kind of walkable behavior, then you can override it. Basically, you inherit from a new kind of walking

22:22 behavior and override the walk method in it with the same talking. Right, let's suppose you can override as many such walkable, talkable or flyable algorithms as you want, just by creating their new child classes again and again. And you do n't have to make any changes in the robot's code because the robot just knows that if I want to fly, then I have to call f dot fly. Now it depends on which class will be called in Flyable. Lately I created a new flying behavior called Fly with Jet which didn't exist yet. But the robot does not know that Fly with Jet has been made. Even now if it calls f dot fly and in a robot I have passed fly with jet, then it will be a method call. So this again is supporting the open close principle as well. So this is the complete Strategy Design Pattern. Now let us quickly look at its code. Let us go. So here is the code as it is

23:07 same as what we discussed. What did we do first? Made strategies. One is our workable robot, which is an interface. Basically in Java there is an interface, in C++ it is called abstract method. It is called an abstract class. There is only one method in this: walk. In this way we created its concrete classes. One is our normal walk, one is our no walk. Ok? In both we overrode the walk method. Walking normally in this. Can't walk in this. In this way we created the rest of the strategies. One is a talkable robot. In that also we have country class, normal talk and no talk. Both of them overrode the top method. Same we have the Flyable robot. They have a method called fly. And we have two different types of concretions. Normal fly and no fly. And overrode the fly method. Simple. Now let's create our Robot class. Now look what we did in robot class? Walkable robots, talkable robots and flyable robots.

23:52 Passed a reference to all three and got it passed in the constructor. Walkable, fly, talkable and flyable. Ok? Now our methods in this class will be walk, talk and fly. Those will be dumb methods because this is a dumb class. What will she do? Simple delegates your requests to other interfaces. For example, what will you do to walk? This one will call the walk behavior that we had. To talk to the same person, the talk behavior will be called talk and to fly, the fly behavior will be called fly. That means she is not handling anything on her own. Walkable, Talkable and Flyable are handling all the work. Its job is to keep those classes within itself just by composition. Ok? Now it had another method projection which was an abstract method and whoever executes this class or inherits this class will define and declare the projection in his own way. Now there are two types of robots:

24:38 companion robots. There is a worker robot. What did the three of them do with Letts? They overrode their projection method and started looking like their own people. But both of them passed all three types of references in their constructor: Vocable, Talkable, and Flyable. And we can decide this dynamically in the main method. So come to the main method. Look what we did here? We made two robots, Robot One and Robot Two. Ok ? One was made as a companion robot, one was made as a worker robot. Now look, we can play with any permutation combination to get the walking, talking and flying behavior we want. So for example in the companion robot, let's say I want a normal walk. Normal talk and no fly behavior is required. And in Robot Two I say no walk, no talk but it should fly normally. There was no fly in it. It had a normal fly. Now I can't change this dynamically. Meaning, tomorrow I can quickly come here and do a Let's No Walk instead of a normal walk.

25:25 And my companion robot will have walking functionality. Then I did not do anything. Let's call these methods and run this code once and see. And it was run. Right? So this is the complete Strategy Design Pattern. Let us go. So now let us target a question which I hope must have come to your mind that brother, you just said that inheritance should be used as little as possible or should it not be used at all ? Composition should be preferred. But are we still not using inheritance here? Like there is a companion robot here. Similarly, we also had a worker robot here. And also if tomorrow we are making robots then they will also be using inheritance. That is absolutely correct. You know you can replace this also. If you want, this is the projection method due to which inheritance is being created. If we remove that as well, then what we will do is

26:12 remove the projection method from here and create a new kind of behavior which is called as lets say projectable. That how it is projected. There will be only one method on it, projection, which was there. Right? Now you can create multiple child classes as per your wish to project any robot. There is one project like a companion robot , there is another project like a worker robot. And you can use that also in composition. So here we will have another projectable interface. Now we'll just call P the dot projection. So how that robot will look will also be decided. Now we don't need any child classes. So we don't need it anymore. Now we can remove it completely. Now we know what we have to do ? To create any robot, we just have to write let's create robot star equals new robot. So in

27:00 this robot, our abstract method has now been removed because there is no method in it. In all these methods, whatever methods there will be, there will be a talk, there will be a walk, there will be a fly and there will be a projection. What would all these methods be doing? You must be delegating your request. Talk must be doing this. Walk must be doing this. The fly will be doing this and the project will be delegating it. So we will directly create a new robot and call our methods in it. Like we will give one talking behavior, one walking behavior, one flying behavior and this time one projection behavior. So this is how we will declare our robot. We do n't need inheritance at all. So this question is also over. Right? Now let's quickly look at a standard UML diagram of how we standardly create it. Ok? So look, first of all we said that we have

27:45 a client. Ok? What is a client? Like here the client we had was the robot class. So this was our client. The one who will basically use these algorithms is our client. Ok? So we created the client class. Ok? Just like we have a client, we have a strategy. Right? Now what was the strategy class ? Here we have created these different types of strategies. Talking, walking or flying strategy. Ok? These are strategy classes. So we have a strategy. Ok? Now this strategy is an abstract class. Right? This is just an interface. So we must have concrete strategies. Right? So we have a lot of concrete strategies. So we have made a lot of concrete strategies here. Let's represent concrete

28:32 strategies. Ok? We have multiple concrete strategies. And this client has a strategy. Right? One has a relationship with strategy. Now you can do it like this, a strategy will have a method let's run which the concrete strategy will execute in different ways and the client will have an object of this strategy. Strategy lets say s and a method will be executed. Ok? If we look inside this execute method, what would generally be written there? Inside the execute method, it will be written that this strategy is S, you call the run method on it. Right? And the run method of this strategy will be called. Now depending upon which strategy we would have passed? Whichever concrete strategy one or two or three is

29:17 passed, its run method will be simply called. So this is the standard UML diagram of Strategy design pattern. Ok ? Now let's look at a real life example to see how strategy patterns can be used in real applications. Ok? You too should think what other examples can there be apart from the one I am giving. Ok? One example is the payment system through LEET. So imagine you have a class with a payment system. Ok? And one method for that could be let's say pay now. Now there can be different strategies for making payments. There may be different ways. There might be different algorithms. Let's have a way to pay via UPI. Isn't it? One way is to pay through credit/debit card and another way is to pay through net banking. So what is all this? There are different

30:02 strategies and payment systems can have multiple strategies. Right? So it may have a relationship. Now whenever we click on Pay Now, it will depend on which strategy we would have passed. UPI, credit debit or net banking that method will be called. His pay now method will be called. So everything will be pay let's pay method. Right? And everyone's pay override will be different in different ways. Isn't it? So this could be one. Apart from this, let me give you another example which is DSS, it will match quite well. Imagine you have a Sorting class and it has the functionality to sort in different ways. Let's say it has a method called sort. And the different ways that we have sorting functionalities. Lately we have quick sort. We have merge sort.

30:48 Insertion sort happens. Right? So all these are different ways, these are different strategies to sort things out. Isn't it? There may be other methods in this too. For example quick sort can also be a normal quick sort. One could do a randomized quick sort from Let's. Right? So this becomes a complete strategy tree. Right? Just like we made it of him. For example, a talkable, walkable or flyable one was made. That's how we got Quick Sort. Similarly, we can have merge sort. Let us write this down as well. Which can be the merge sort from late? One let's get it sorted in normal mode. One of yours is in place from lets. Isn't it? Some such insertions can be made. Right? So you understand that this is also an example of strategy. There may be a has a relationship in this too. And whenever you call sort method, depending upon which strategy you

31:34 passed? Quick Merge or Insertion Sort and which method did it exactly pass. Sorry which real concrete class did I pass. Its sort method will be called. So this is also a real life example. I hope you understood these real life examples and can think of some better examples of your own where Strategy Design Pattern can be used. By the way this is one of the most useful design patterns which is used in building any application. In fact, whenever you give an interview, then the strategy pattern will definitely get included in almost all the applications which you are making, whose design architecture you are creating. So let us conclude it quickly. I have written some concluding points here. You can pause the video and you can see whatever we discussed in this lecture. This was the whole strategy design pattern. I hope you understood this. See you in the next video with a different design pattern. Till then thank you so much.