今天我们来学习命令模式，这个设计模式使用频率较低，也不不太好理解，并且只应用在特定的环境下。所以，暂时不准备深入的学习，了解即可。
概述
命令模式：（Command Pattern）将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志。以及支持可撤销的操作。
通俗一点讲就是将一系列的请求命令封装起来，不直接调用真正执行者的方法，这样比较容易扩展。
何时使用：
- 在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
UML 类图：
角色组成：
-
客户端(Client)角色： 创建一个具体命令(ConcreteCommand)对象并确定其接收者。
-
命令(Command)角色： 声明了一个给所有具体命令类的抽象接口。
-
具体命令(ConcreteCommand)角色： 定义一个接收者和行为之间的弱耦合；实现execute()方法，负责调用接收者的相应操作。execute()方法通常叫做执行方法。
-
请求者(Invoker)角色： 负责调用命令对象执行请求，相关的方法叫做行动方法。
-
接收者(Receiver)角色： 负责具体实施和执行一个请求。任何一个类都可以成为接收者，实施和执行请求的方法叫做行动方法。
通用代码
接受者角色
public class Receiver {
// 真正执行命令相应的操作
public void action() {
System.out.println("执行命令对应的操作");
}
}
抽象命令角色
public interface Command {
void execute();
}
具体命令角色
public class ConcreteCommand implements Command {
//持有相应的接收者对象
private Receiver receiver = null;
@Override
public void execute() {
//通常会转调接收者对象的相应方法，让接收者来真正执行功能
receiver.action();
}
public ConcreteCommand(Receiver receiver){
this.receiver = receiver;
}
}
请求者角色
public class Invoker {
/**
* 持有命令对象
*/
private Command command = null;
/**
* 构造方法
*/
public Invoker(Command command){
this.command = command;
}
/**
* 行动方法
*/
public void action(){
command.execute();
}
}
客户端角色
public class Client {
public static void main(String[] args) {
//创建接收者
Receiver receiver = new Receiver();
//创建命令对象，设定它的接收者
Command command = new ConcreteCommand(receiver);
//创建请求者，把命令对象设置进去
Invoker invoker = new Invoker(command);
//执行方法
invoker.action();
}
}
结果：
执行命令对应的操作
具体实例我觉得这篇博文中的例子是很好的：设计模式之命令模式_菜鸟博客-CSDN博客_命令模式
应用场景
-
Struts2中action中的调用过程中存在命令模式
-
数据库中的事务机制的底层实现
-
命令的撤销和恢复：增加相应的撤销和恢复命令的方法（比如数据库中的事务回滚）
总结
命令模式与策略模式的区别：
策略模式包含策略的定义、创建和使用三部分，从代码结构上来，它非常像工厂模式。它们的区别在于，策略模式侧重“策略”或“算法”这个特定的应用场景，用来解决根据运行时状态从一组策略中选择不同策略的问题，而工厂模式侧重封装对象的创建过程，这里的对象没有任何业务场景的限定，可以是策略，但也可以是其他东西。从设计意图上来，这两个模式完全是两回事儿。
在策略模式中，不同的策略具有相同的目的、不同的实现、互相之间可以替换。比如，BubbleSort、SelectionSort 都是为了实现排序的，只不过一个是用冒泡排序算法来实现的，另一个是用选择排序算法来实现的。而在命令模式中，不同的命令具有不同的目的，对应不同的处理逻辑，并且互相之间不可替换。
