Transfer: blog.csdn.net/No\_Game\_N… ?

Command mode

The command model is easy to understand. For example, when a commander gives an order to a soldier to do something, the role of the commander is to give the command, and the command is passed on to the soldier, and the soldier carries it out. The good thing about this process is that the three are decoupled from each other, so that no one has to rely on anyone else to do their job, and the commander wants results, not how the soldier achieves them. Let’s look at the diagram:



Invoker (commander), Receiver (soldier), MyCommand (Command), MyCommand (Receiver), MyCommand (Command), MyCommand (Receiver)

public interface Command {  
    public void exe();  
}  
public class MyCommand implements Command {  
  
    private Receiver receiver;  
      
    public MyCommand(Receiver receiver) {  
        this.receiver = receiver;  
    }  
  
    @Override  
    public void exe() {  
        receiver.action();  
    }  
}  
public class Receiver {  
    public void action(){  
        System.out.println("command received!");  
    }  
}  
public class Invoker {  
      
    private Command command;  
      
    public Invoker(Command command) {  
        this.command = command;  
    }  
  
    public void action(){  
        command.exe();  
    }  
}  
public class Test {  
  
    public static void main(String[] args) {  
        Receiver receiver = new Receiver();  
        Command cmd = new MyCommand(receiver);  
        Invoker invoker = new Invoker(cmd);  
        invoker.action();  
    }  
}  
123456789101112131415161718192021222324252627282930313233343536373839404142
Copy the code

The purpose of command mode is to achieve decoupling between the sender and the executor of the command, and realize the separation of request and execution. Those familiar with Struts should know that Struts is actually a technology to separate request and presentation, which must involve the idea of command mode!

Intents: Encapsulate a request into an object that allows you to parameterize customers with different requests.

Main solution: in the software system, the behavior requester and behavior implementers are usually a tightly coupled relationship, but in some situations, such as the need to record, undo or redo the behavior, transaction processing, this can not resist the change of the tightly coupled design is not appropriate.

When to use: In some situations, such as “record, undo/redo, transaction” processing of behavior, this tight coupling that cannot resist change is not appropriate. In this case, how to decouple the “behavior requester” from the “behavior implementor”? Loose coupling can be achieved by abstracting a set of behaviors as objects.

How to solve this problem: Execute commands through caller calling receiver in order: caller → receiver → command.

Key code: define three roles: 1, received real Command execution object 2, Command 3, invoker use Command object entry

Application example: There is only one Action core controller ActionServlet in Struts 1, which is equivalent to Invoker, while classes in the model layer will have different model classes with different applications, which is equivalent to specific commands.

Advantages: 1, reduce the coupling degree of the system. 2. New commands can be easily added to the system.

Disadvantages: Using command mode can cause some systems to have too many specific command classes.

Usage scenarios: The command mode can be used wherever commands are considered, for example: 1. Each button in the GUI is a command. 2. Simulate CMD.

Note: The system needs to support Undo and Redo operations. You can also consider using the command mode, see extension of the command mode.