In this lesson, we will talk about another type of design pattern called the Command Pattern. The command pattern encapsulates the request as an object of its own. Usually, when one object makes a request for a second object to do an action, the first object would call a method of the second object and the second object would complete the task. In this situation, the sender object directly has to communicate with the receiver object. Instead of having these objects directly communicating with each other, the command pattern creates a command object in between the sender and receiver. This way, the sender doesn't need to know about the receiver and the methods to call. Think of it like how a boss in a company uses memos to carry out tasks. For example, if the boss needed a worker to schedule a meeting and also needed another worker to talk to an important client about business, the boss can use memos. The boss is a very busy person and may not have time to remember which workers do what jobs and won't have time to walk to the different workers to ask them to complete the tasks. Instead, the boss could just write the tasks down onto a sticky note and a secretary could give these to the workers that can complete them. The boss is encapsulating his commands into memos, the way requests could be encapsulated into command objects in software. So, you may have noticed in the previous example, that if a boss creates a memo, there needs to be some sort of secretary that gets these memos to the actual receiver to get this memo completed. Similarly, in software, a sender object creates a command object. But what actually makes the command object do what it's supposed to do and invoke the specific receiver object to complete the task? This is where an invoker comes in. The command pattern has another object that invokes the command objects to complete whatever task it is supposed to do, called the invoker. A command manager can also be used which basically keeps track of the commands, manipulates them and invokes them. Think of the invoker like the secretary in the company example. The secretary keeps track of the memos, making sure that the memos are executed at the right time. So, where can you implement the command pattern in your software? There are many different purposes for using the command pattern. One purpose of using the command pattern is to store and schedule different requests. When an object calls a method of another object, you can't really do anything to the method calls. Turning the different requests in your software into command objects can allow you to treat them as the way you would treat other objects. You can store these command objects into lists, you can manipulate them before they are completed, or you can put them onto a queue so that you can schedule different commands to be completed at different times. For example, you can use the command pattern to have an alarm ring in calendar software. When an event is created in the calendar, a command object could be created to ring the alarm. This command could be put onto a queue, so that the command can be completed later when the event is actually scheduled to occur. Another important purpose of the command pattern is allowing commands to be undone or redone. Like how you can undo or redo edits in a document. This example will be easier to understand by using a diagram. Suppose that you are creating text editing software. There can be many different commands that can be executed in your text editing software like delete text, change font, pixel text and so on. To achieve redo and undo functionality, your software will need two lists, a history list which holds all the commands that have been executed, and a redo list which would be used to put commands that have been undone. Every time a command is requested, a command object is created and executed. Every time a command is completed, that command goes to the history list. Now, what if the user wanted to undo a command? Well, the software would look at the history list and look at the most recent command executed. The software would ask this command to undo itself and then put it on the redo list. Let's undo another command. If the user needs to redo, the software would take the most recent command undone in the redo list and ask the command to execute again. Then move it onto the history list again. Let's redo another command. The redo list will also need to be emptied every time a command is executed. Because usually, you can't redo a previous edit after a new edit has already been made. So, that's how you can use the command pattern to create your text editing software. This redo/undo functionality doesn't have to be just for text editors. You can use a command pattern to allow redo/undo on any type of application. The important thing is that the command pattern lets you do things to request that you wouldn't be able to do if they were simple method calls from one object to the other. You can store these commands in a log list also. So that if your software program has an unexpected crash, you can allow your users to redo all the recent commands. Creating these requests as objects allows you to create very useful functionality in your software programs. How might the command pattern look in a UML diagram and in your source code? Here's how it would look in a UML diagram. You have a command super-class and all commands will be instances of sub-classes of this command super-class. Super-class defines the common behaviors of your commands. Each command will have the methods execute, unexecute and isReversible. The execute method will actually do the work that the command is supposed to do, unexecute will do the work of undoing the command, and isReversible determines if the command is reversible, returning true if the command can be undone. There could be some commands that can't be undone. For example, save as a command that doesn't really make sense to be undone. You can't really unsave a work that has been saved. These concrete command classes will call on specific receiver classes to deal with the actual work of completing the command. If we look into more details of concrete command class, for example pasting text, we can see how a command object should be. We can see that the paste command extends the command super-class. The paste command object also keeps track of where the text will be inserted and what will be inserted. This is a very important aspect of command objects. They must keep track of a lot of details on the current state of the document in order for commands to be reversible. In this case, the paste command is also a reversible command because you can delete the object you just pasted. So, what will return true if isReversible is called and must keep track of where the text was pasted. When the execute and unexecute methods are called, this is where the command object actually calls on the receiver, which in this case is the document to actually complete the work. The source code for the invoker is done in simple steps. First, it will need a reference to the command manager, which is the object that manages the history and redo lists. The invoker then creates the command object with the information needed to complete the command, then calls the command manager to execute the command. There are many benefits that come from using the command pattern. As I've mentioned before, it allows you to manipulate the commands as objects the way you could not do with method calls. Working with command objects allows you to add the functionalities I mentioned earlier, like putting commands into queues and adding an undo/redo function. Another main benefit of the command pattern is that it decouples the objects of your software program. When you have a class that wants to make a request, that class doesn't need to know about the other objects in the software system. It can simply just create a command object and let the command object deal with the work by invoking the receiver objects, like with the boss memo example I mentioned earlier. The object doesn't need to know who deals with the request anymore, like how the boss doesn't need to know which worker will deal with the task. The command pattern also allows you to pull out logic from your user interfaces. Usually, code-to-handle requests is put into the event handlers of user interfaces. However, it doesn't really make sense to have a lot of application logic sitting in your user interface classes. The user interface classes should only be dealing with user interface issues like getting information to and from the user. Instead, the command pattern creates a new layer which is where these command objects will go. Every time a button is clicked, it will create a command object instead. And that is where the logic will set. These command objects are independent of your user interface. So, it makes adding changes like new buttons to your software's user interface easier and faster. You can turn each and every service in your system into an object of its own and allow much more flexible functionality. Next time you're creating an application, try applying the command pattern. Soon you'll see that using this pattern can really make your software programs versatile and easier to maintain. And you'll want to use it on every software you create. Good luck.
