Design Mode-command mode

Command mode definition:Encapsulate requests as objects to parameterize other objects using different requests, queues, or logs. The command mode also supports unrecoverable operations. First, we focus on the word "command. The command is interpreted as a command and mandatory document issued by the State Administration and its leaders. To put it bluntly, the sender and executor are required to execute commands. In addition, the sender and executor perform their respective duties. The sender is only responsible for issuing orders, and even he does not know how to execute this command, but the executor is only responsible for executing this command, he does not need to know how to send orders. In many cases, he is not qualified to send orders. The following uses a simple "Computer Boot" as an example to describe that a person plays the role of the sender, while a boot component on a computer plays the role of a command executor. You don't need to know how to execute the command on your computer. You just need to press the power-on key. The specific power-on operation is completed by the computer power-on component, this achieves the decoupling effect between the sender and executor. After people know how to send an order, they can perform a lot of operations by clicking the button, such as opening a TV, opening a door, switching the air-conditioning mode, etc, people only need to know that "click the key" to issue a number, and the specific operation is completed by the corresponding command recipient. The following describes in detail what command mode is:The command mode involves several common classes: Command, concretecommand, client, invoker, and aggreger. The specific name can be determined by the user according to his or her habits. If the user contacts the actual operation of "Computer Boot", the Mappings of these categories are as follows:

• Command -----> general interface of the command
• Concretecommand -----> boot command
• Client -----> User
• Invoker -----> line between the host key and the boot component
• Receiver -----> power-on Component

Concretecommand implements the universal command interface command, which is the boot command here, which encapsulates the command receiver and the method for triggering command execution. The client (User) wants to start the system. Therefore, he needs to send a command to start the system. The user needs to create a command and specify that the command is a command to start the system. The user presses the key to create a command, and the user presses the on key to create a boot command. After you press the power-on key, invoker (the line between the power-on key and the power-on Component) notifies the power-on component of this command. After the power-on Component receives the command, it starts to work, then the computer starts up. In this process, the user does not need to know how the computer is turned on, but only needs to send a number to start the command. The specific programming implementation is as follows (the UML diagram is as follows ):  

1 first define a common command interface: 2/** 3 * command interface 4 * @ author apache_xiaochao 5*6 */7 public abstract class command {8 9 protected receiver; // command receiver 10 11/** 12 * Set receiver 13 * @ Param receiver14 */15 public command (receiver er receiver) {16 super (); 17 this. extends ER = extends er; 18} 19 20/** 21 * command execution function 22 */23 public abstract void execute (); 24}

1. define the specific boot command (the general class name is used here, which can be replaced with a more intuitive class name in practice ): 2/** 3 * specific command 4 * @ author apache_xiaochao 5*6 */7 public class concretecommand extends command {8 9/** 10 * set the command recipient 11 *@ param receiver12 */13 public concretecommand (receiver) {14 super (guest ER); 15 // todo auto-generated constructor stub16} 17 18 @ override19 public void execute () {20 // The main body of the command, the command itself does not execute a specific operation, but sends a notification to the receiver of the command. The specific operation is performed by the receiver of the command to perform 21 worker er. dosomething (); 22} 23 24}

1. Define the boot component (the general class name is used here and can be replaced with a more intuitive class name in practice): 2/*** this is a command receiver, execute Command 4 * @ author apache_xiaochao 5*6 */7 public class er {8 9/** 10 * boot function 11 */12 public void dosomething () {13 system. out. println ("command receiver: Windows is starting... "); 14} 15}

1. Define the user class: 2/** 3 *. Create a command, and set the command receiver 4 * @ author apache_xiaochao 5*6 */7 public class client {8 9/** 10 * to create a command, and set the recipient of the command 11 */12 public command createcommand () {13 receiver er receiver ER = new receiver Er (); 14 // create a command, and specify the command receiver 15 command = new concretecommand (receiver ER); 16 return command; 17} 18}

1. Define the line between the on-premises key and the boot component (the general class name is used here, which can be replaced with a more intuitive class name in practice ): 2/** 3 * Command Transmission Class 4 * @ author apache_xiaochao 5*6 */7 public class invoker {8 9 private command; 10 11/** 12 * the recipient of the notification command executes the command 13 */14 public void policyreceiver () {15 command.exe cute (); 16} 17/** 18 * GET command 19 * @ Param command20 */21 public void setcommand (command) {22 This. command = command; 23} 24}

1 public class driver {2 public static void main (string [] ARGs) {3 // press the open key 4 Client client = new client (); 5 command = client. createcommand (); // The client creates a Command 6 // Communication Line Transmission command 7 invoker = new invoker (); 8 invoker. setcommand (command); // get the user-created command 9 invoker. notifycycler (); // pass the command to notify the startup component that someone wants to boot 10} 11}

The general process of the entire program is:

1. The client creates a command and specifies the receiver of the command.
2. Invoker sends a command to notify the command receiver to execute the command
3. The receiver receives commands, parses and executes

The command details are encapsulated in the command object. You do not have to worry about what the command looks like. You only need to create and specify the receiver. The receiver will parse and execute the command on its own. The commands here refer to a single command. When you press the enable key, you can also trigger a series of operations, such as the optical drive pop-up at the same time (just for example, in reality, this is definitely not desirable.) It is called a macro command. Of course, we can also define the Undo function in the command mode (for example, if you mistakenly press the enable key and want to cancel the boot), the idea is to record the previous operation or several times, then, execute the corresponding reverse operation. Summary:

1. The command mode decouples the object that sends the command from the object that executes the command.
2. The sender and executor communicate with each other through the command object. The command object encapsulates the command receiver and one or more actions.
3. The command can be undone by implementing an undo () method to return to the status before execute () is executed.
4. Macro commands are a simple extension of commands. You can call multiple commands and revoke them.
5. The command can also be used to implement logging and transaction systems.

Design Mode-command mode