The problem is that you may want to ask an object to do something, but you don't know exactly when the object will carry out the request or exactly how it will do it.
The solution, as shown in Figure 5.4, is to create a Command object that represents which command you want executed, possibly with information about which target object is supposed to be affected by the command's execution.
Often the Command pattern is used in partnership with a CommandProcessor that holds the collection of commands that still need to be executed. The CommandProcessor can be derived from an array template or a linked list template.
The Windows operating system uses something like the Command pattern, although the pattern is not implemented in a fully object oriented way. In Windows all commands are stored as message structures that have an integer messageID specifying the type of command to be executed. Rather than individually implementing an execute method, the messages pass off the execution task to a big switch statement in the Windows code, with the switch looking at the value of the messageID.
In the Pop Framework, we do a similarly half-hearted implementation of the Command pattern; we use a cServiceRequest structure and pass the task of executing the command off to switch in the code of a cBiota object that holds our command queue.
A bit more detail. When we carry out an update of the game world, we walk through a list of critters and call an update method for each of them. When an object dies, it's not practical to remove it from the simulation until we're done updating all the other objects, otherwise one of the not-yet-updated objects may still need to finish interacting with the about-to-die object. What we do is maintain an array of cServiceRequest objects, where each cServiceRequest holds a cCritter *_pclient and CString _request field. And at a certain time specified by the cGame::step template, we make a call to the cBiota::processServiceRequests method that carries out each of the pending commands.