problem introduction
look at a specific need
1) We bought a set of smart home appliances, including lights, fans, refrigerators, and washing machines. We only need to install an app on our mobile phone to control the work of these home appliances.
2) These smart home appliances come from different manufacturers. We don't want to install an app for each type of home appliance and control them separately. We hope that only one app can control all smart home appliances.
3) To realize the need of an app to control all smart home appliances, each smart home appliance manufacturer must provide a unified interface for the app to call. At this time, the command mode can be considered.
4) The command mode can decouple the "action requester" from the "action executor" object.
5) In our example, the action requester is the mobile app, and the action executor is each manufacturer's a home appliance
Basic introduction to command mode
basic introduction
1) Command Pattern: In software design, we often need to send requests to certain objects, but we don’t know who the recipient of the request is, nor what the requested operation is. We only need to Just specify the specific request receiver at runtime. At this time, you can use the command mode to design.
2) The naming mode enables the request sender and the request receiver to eliminate the coupling between each other, making the calling relationship between objects more flexible. Achieve decoupling.
3) In the naming mode, a request will be encapsulated into an object so that different parameters can be used to represent different requests (that is, naming), and the command mode also supports undoable operations.
4) Easy to understand: the general issues an order, and the soldiers execute it. There are several roles: general (the order issuer), soldier (the specific executor of the order), and order (connecting the general and the soldier). Invoker is the caller (general), Receiver is the callee (soldier), MyCommand is the command, implements the Command interface, and holds the receiving object
Principle class diagram of command mode
Explanation of the principle class diagram
1) Invoker is the role of the caller
2) Command: is the role of the command, all the commands that need to be executed are here, it can be an interface or an abstract class
3) Receiver: the role of the receiver, knowing how to implement and execute a request-related operation
4) ConcreteCommand: Bind a receiver object to an action, call the corresponding operation of the receiver, and implement execute
Command Patterns to Solve Smart Living Projects
Analysis and Diagram of Ideas
Code
Command
public interface Command {
//执行动作(操作)
public void execute();
//撤销动作(操作)
public void undo();
}LightReceiver
public class LightReceiver {
public void on() {
System.out.println("电灯打开了.. ");
}
public void off() {
System.out.println("电灯关闭了.. ");
}
}LightOffCommand
public class LightOffCommand implements Command{
LightReceiver light;
// 构造器
public LightOffCommand(LightReceiver light) {
super();
this.light = light;
}
@Override
public void execute() {
light.off();
}
@Override
public void undo() {
light.on();
}
}LightOnCommand
public class LightOnCommand implements Command{
LightReceiver lightReceiver;
public LightOnCommand(LightReceiver lightReceiver) {
this.lightReceiver = lightReceiver;
}
@Override
public void execute() {
lightReceiver.on();
}
@Override
public void undo() {
lightReceiver.off();
}
}NoCommand
There is no command, that is, empty execution: used to initialize each button, when the empty command is called, the object does nothing
In fact, this is a design pattern, which can save the empty judgment
public class NoCommand implements Command{
@Override
public void execute() {
}
@Override
public void undo() {
}
}RemoteController
public class RemoteController {
// 开 按钮的命令数组
Command[] onCommands;
Command[] offCommands;
//撤销命令
Command undoCommand;
// 构造器，完成对按钮初始化
public RemoteController() {
onCommands = new Command[5];
offCommands = new Command[5];
for (int i = 0; i < 5; i++) {
onCommands[i] = new NoCommand();
offCommands[i] = new NoCommand();
}
}
// 给我们的按钮设置你需要的命令
public void setCommand(int no, Command onCommand, Command offCommand) {
onCommands[no] = onCommand;
offCommands[no] = offCommand;
}
// 按下开按钮
public void onButtonWasPushed(int no) { // no 0
// 找到你按下的开的按钮， 并调用对应方法
onCommands[no].execute();
// 记录这次的操作，用于撤销
undoCommand = onCommands[no];
}
// 按下开按钮
public void offButtonWasPushed(int no) { // no 0
// 找到你按下的关的按钮， 并调用对应方法
offCommands[no].execute();
// 记录这次的操作，用于撤销
undoCommand = offCommands[no];
}
// 按下撤销按钮
public void undoButtonWasPushed() {
undoCommand.undo();
}
}Notes and details of command mode
1) Decouple the object that initiates the request from the object that executes the request. The object that initiates the request is the caller. The caller only needs to call the execute() method of the command object to make the receiver work without knowing who the specific receiver object is and how it is implemented. The command object will be responsible for the receiver to execute The action of the request, that is to say: the decoupling between the "request initiator" and the "request executor" is realized through the command object, and the command object acts as a bridge.
2) It is easy to design a command queue. As long as the command object is placed in the queue, the command can be executed in multiple threads.
3) It is easy to realize the undo and redo of the request.
4) Insufficient command mode: it may cause some systems to have too many specific command classes, which increases the complexity of the system 5) The
empty command is also a design pattern, which saves us the operation of judging empty. In the above example, if the empty command is not used, every time we press a button, it will be judged as empty, which brings some troubles to our coding.
6) Classic application scenarios of the command mode: every button on the interface is a command, cancel/restore of simulated CMD (DOS command) order, trigger-feedback mechanism