72: Design Patterns: Command.

The command behavioral pattern allows you to represent an action that you want to perform as an object that can be copied from place to place and performed at a later time if you want. You start by creating an abstract class called Command with a method called execute. It will help if you give the execute method a parameter so that it’ll know what the target of the command should be. You can also declare a method called undo which will allow you to implement a full-featured undo/redo system in your application. Then you declare concrete classes that derive from the Command class that implement the execute method. The episode explains how to implement a command to cause a character in a game to move forward. Now that you have this, you can refer to the command class anywhere in your code that you need to perform some action. This could be a user-initiated action such as pressing a key or maybe an automated action that’s performed on a schedule. You can also pass command objects around in your code. Maybe you have some code that detects what keys are being pressed. This code could first use the command pattern to map commands to different keys. Once it finds the correct Command object, it can pass that Command to other code that’s aware of the target. This decouples the command from the mechanism or button used to trigger the command and from the target. Now code can use the moveForwardCommand class object to move any character in the game forward. Listen to the full episode or you can also read the full transcript below. Transcript The basic description says that this pattern lets you turn requests into objects that you can then provide to other code to run without knowing what is actually happening, that you can add to a list of actions to be performed, and that you can log to record what happened. It also mentions undoing actions. This is a design pattern that is extremely useful if you understand it. If you don’t understand it, it’s just as easy to ignore. Let’s follow our adventurous hero as the player guides the hero along a wilderness path. One very simple command is to move forward. Now you could write code to move the hero forward when an arrow key is pressed on the keyboard. But what if you also have a controller with thumb pads? Do you duplicate this code in both locations? What if you allow the user to control the hero with a mouse? All these places need to be able to move the hero forward. And we haven’t even begun to think about how we would handle an advanced feature that allows players to map buttons of their choosing to various commands. It’s obvious that we need something that represents the idea of moving forward. But it’s not so obvious what this should be. Before we get too far, I’d just like to point out that this pattern applies to almost any command or action that a user can initiate in your application. From opening documents, saving work done so far, starting over, or changing a preference setting. Anything you can imagine going into a menu bar or any action that user can initiate through the keyboard. Even actions that might run on a schedule automatically. These are all excellent candidates for the command pattern. So let’s say that we have some button X that when pressed will cause the hero to move forward. Somewhere there will be code that detects if the X button is pressed. Instead of that code calling some function like moveHeroForward what we instead do is first create an abstract base class or an interface called Command that has a virtual method called execute. Then we can have a concrete class called moveForwardCommand that inherits from the Command class and implements the execute method. I’ll get to this part in just a moment. The next step is to declare pointers or references to various Command instances and name each of these after each of the buttons. The buttons themselves aren’t swapped or remapped. It’