A request is encapsulated into an object, so that you can use different requests to parameterize the client, queue requests or record request logs, which can provide command cancellation and recovery functions.
For example, the commander ordered the soldiers to do something. From the perspective of the whole thing, the commander's role is to issue a password, and the password is passed to the soldier's ears, and the soldier executes it. The good thing about this process is that the three are decoupled from each other. Neither party needs to rely on others, but only needs to do its own thing. The commander wants results, not how the soldiers did it.
Class Diagram
Code example
1. class Invoker {
2. private Command command;
3. public void setCommand(Command command) {
4. this.command = command;
5. }
6. public void action(){
7. this.command.execute();
8. }
9. }
10.
11. abstract class Command {
12. public abstract void execute();
13. }
14.
15. class ConcreteCommand extends Command {
16. private Receiver receiver;
17. public ConcreteCommand(Receiver receiver){
18. this.receiver = receiver;
19. }
20. public void execute() {
21. this.receiver.doSomething();
22. }
23. }
24.
25. class Receiver {
26. public void doSomething(){
27. System.out.println("接受者-业务逻辑处理");
28. }
29. }
30.
31. public class Client {
32. public static void main(String[] args){
33. Receiver receiver = new Receiver();
34. Command command = new ConcreteCommand(receiver);
35. //客户端直接执行具体命令方式（此方式与类图相符）
36. command.execute();
37.
38. //客户端通过调用者来执行命令
39. Invoker invoker = new Invoker();
40. invoker.setCommand(command);
41. invoker.action();
42. }
43. }
Through the code, we can see that when we call, the timing of execution is first the caller class, then the command class, and finally the receiver class. That is to say, the execution of a command is divided into three steps, and its coupling is much lower than encapsulating all operations in a class, and this is the essence of the command mode: the caller of the command Separate from the executor, so that both parties do not need to care about how the other party operates.
The purpose of the command mode is to achieve the decoupling between the issuer and the executor of the command, and realize the separation of the request and the execution . Students familiar with Struts should know that Struts is actually a technology that separates the request and the presentation, which must involve the command mode. thought!
The structure of the command pattern
As the name implies, the command mode is an encapsulation of commands. First, let's take a look at the basic structure of the command mode class diagram:
- Command class : is an abstract class in which the commands that need to be executed are declared. Generally speaking, an execute method is required to execute the command.
- ConcreteCommand class : the implementation class of the Command class, which implements the methods declared in the abstract class.
- Client class : the final client calling class.
The role of the above three classes should be relatively easy to understand, let's focus on the Invoker class and Recevier class.
- Invoker class : the caller, responsible for invoking commands.
- Receiver class : receiver, responsible for receiving commands and executing commands.
The so-called encapsulation of commands, to put it bluntly, is nothing more than writing a series of operations into a method, and then for the client to call it, reflected on the class diagram, only a ConcreteCommand class and Client class can complete the command Encapsulation, even if it goes further, in order to increase flexibility, you can add another Command class for proper abstraction. What is the role of the caller and receiver?
In fact, you can think about it from another angle: If you simply encapsulate some operations as a command for others to call, how can it be called a mode? Command mode, as a behavioral mode, must first be low-coupling. Only when the coupling is low can flexibility be improved. The purpose of joining the two roles of caller and receiver is precisely for this.
Advantages and disadvantages of command mode
First of all, the encapsulation of the command mode is very good: each command is encapsulated, and for the client, what function is needed to call the corresponding command without knowing how the command is executed. For example, there is a set of file operation commands: new file, copy file, delete file. If these three operations are encapsulated into one command class, the client only needs to know that there are these three command classes. As for the logic encapsulated in the command class, the client does not need to know.
Secondly, the command mode is very extensible. In the command mode, the receiver class will generally encapsulate the most basic operations, and the command class will re-encapsulate these basic operations. When adding new commands , The writing of command classes generally does not start from scratch. There are a large number of receiver classes to call, and there are also a large number of command classes to call, the code reusability is very good. For example, in file operations, we need to add a command to cut files, and we only need to combine the two commands of copying files and deleting files, which is very convenient.
Finally, let me talk about the shortcomings of the command mode, that is, if there are many commands, it will be a headache for development. In particular, many simple commands are implemented in a few lines of code. If you use the command mode, no matter how simple the command is, you need to write a command class to encapsulate it.
Applicable scenarios of command mode
For most of the request-response mode functions, it is more suitable to use the command mode. Just as the command mode definition says, the command mode is more convenient for implementing functions such as logging and canceling operations.