Introduction to the Command Design Pattern

Paulo Dichone | Android, Java, Flutter Developer and Teacher
A free video tutorial from Paulo Dichone | Android, Java, Flutter Developer and Teacher
Software Engineer - Android, Java, Flutter, Dart and Teacher
4.4 instructor rating • 13 courses • 114,792 students

Learn more from the full course

Java Design Patterns: The Complete Masterclass - 21 Patterns

Master Java Design Patterns and Write Robust and Extensible Software - MVC, Observable, Singleton, Facade, Builder...

09:50:47 of on-demand video • Updated February 2020

  • Master Java Design Patterns
  • Apply Design Patterns to Real-World Projects
  • Build Software that's Robust and Flexible Using Java Design Patterns
  • Solve common Software architecture problems with Java Design Patterns
English [Auto] Oh right. So let's go ahead and take a look at the command pattern. Now the command pattern is a very useful and interesting design pattern and it's also used when we need a some sort of a one size fits all kind of situation where depending on the situation depending on what we are providing the same command right we'll execute the appropriate action or actions from different requests. OK. Now that's a mouthful. Let's go ahead and take a look at an example so that we can hopefully wrap our heads around this command pattern before we go further any further here. I just want to say that I am not a game player. Growing up I always wanted to own one of these. But parents were too poor so we couldn't have a Gameboy but I had friends who had game boys going out and so forth so. Disclaimer I'm not a gamer and some things that I may use in this analogy may make you cringe and happy and I apologize for that. I hope you'll forgive me. But in any case so we've seen most of us have actually seen a game console or a Gameboy such as the one you looking at right now. So deconstructing this system in the very upper level in a very high level we will have a game card which we take the game card and we insert into our game boy game console here so that we can then reload again. Right. And then we have of course our game console controllers that allow us to control. So if you want the game that we are playing from aren't game card for the character to actually load and start playing and going up and down and do all the movements and the characters in the game do we use our console controllers our controllers and of course we have the actual game console which is the game itself. So inside it has all of the machinery or all the technology that allows us to actually create to actually play the game. OK we all agree on this very simple deconstructing at a very high level. Now if we go back and look at this same concept and the same hierarchy the same way of looking at the game console but in the in the command pattern way of seeing it you notice the language changes a little bit because now instead of calling our game call we call it a request or request would be something that we are requesting in certain games so this game could be Mario. Or maybe there's other versions of Mario or maybe even different games that Nintendo could can create. Right so we put that request into our invoker when this case will be our console the Gameboy because it will be able to invoke this request and do things to it right. And then of course our commands controllers will allow us to turn our device on or off. And then also allow us to guide the characters in this case. Mario could be one of the characters in the Gameboy right now Mario or any other characters in the game boy and the game that we're playing are called receivers. Because these are the entities that receive whatever we come from our request and what our invoker is able to read from our request right from our request and also from our command. So if we are playing the game and we want to jump up this way we click on one of those controllers arrow up and Mario will jump back. What are we doing here. We are trying to understand the command pattern in the sense that the console itself is one entity. Now the request in this case the game card could be any type of energy or any type of game. Right. So Nintendo could create different characters with different kind of games. The moment you take the request card the game itself and you put on a console and you start playing it. The commands jump right left right and so forth on and off will still be valid regardless of what kind of game we are playing. OK. There is. That's why we call is the command because we're compartmentalizing the commands in such a way that it doesn't matter what kind of request we're getting. It will always know how to invoke those requests and those commands appropriately depending on depending on the requests that we're making. And it's a pattern that's used vastly in the field and allows us to create systems or code or software that is more flexible efficient and easy to maintain because now we can have all sorts of requests also are all different types of request and the invoker doesn't have to know anything about that request. You just know that it needs to invoke whatever it to be invoke into our commands and all commands will know what to do with the receivers. Perfect So if we look at a pattern design if we were to take our game boy Nintendo Gameboy and break it up and look at the class creation and interaction then you will see that of course all through life we have the kind of application that we will be using our system. Our game play. And then you notice now we have the Gameboy or the console which is the invoker. So internally the invoker the one that invokes has functions inside it knows what to do when arrow up is called. So when we tap on the arrow up it knows what to do. Left right and down. That's all it does. It knows how to delegate that how to do that. This Gameboy of course has interactions interacting with the command interface. Why. Because we need to have the command that has all the commands that allows us to execute those commands rights era up left right and down. So the invoker to our cable console here will hold a command and at some point asks the command to carry out a request by calling its execution method. I didn't show here the execute method but you will comply because the Gameboy is connected to the command interface which has executed and then our command class interface. That's where we declare all of commands. So as you know the command is actually executed through the execute method which asks a receiver to perform an action. In this case the receiver will be a character. In this case will be our Mary-Jo character which is a receiver so it knows exactly once it receives those commands he knows OK. The command that was received was to go up and then indeed I will go up go left go left right right. Move down and moved down and to the right here we have the concrete implementation of the command. So in this case we could use Mario up command which will know how to execute up. And again the beauty here is that we can have as many Mario character or as many receivers as we want. Any class can be a receiver create so we can have different characters such as Kirby. I think that's one of the Nintendo characters and so many others and we can always and we can always expect that depending on the game that doesn't matter what the request or what game we're playing. All of those commands will work flawlessly without having to worry too much on the differences of that of the game. Right now let's go ahead and of course important we have to do the definition. The definition that I've found says that the command pattern encapsulates a request as an object. In this case for instance the game card is our request so it makes it as an object thereby letting you parameterize other objects with different requests queues or log requests. So again like I said for now we are dissociating everything in or making sure that doesn't matter what kind of request we are adding what kind of request we have in this case the game card if it's game from 1982. You put it in. It will still work flawlessly. We start using the commands to jump will celebrity John. Mario will jump. If you put another game for instance from 1972 probably didn't have that game in those days. In case you get the idea here it doesn't matter what request it will always know what to do with those commands because we can parameterize other objects with different requests to be added into our little system here and everything will still work OK. Perfect so I'll see the next video where are we going to put together in code. The command pattern perfect I'll see you next.