设计模式之命令模式

一：定义

命令模式（Command Pattern）将请求封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式支持可撤销的操作。

命令模式可以对发送者额接受者完全解耦，发送者也接收者之间并没有直接的联系，发送者只需要知道如何发送请求，不需要关心请求是如何完成了。这就是命令模式，命令模式将方法调用给封装起来了。

意图：将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。

主要解决：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。

何时使用：在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。

如何解决：通过调用者调用接受者执行命令，顺序：调用者→命令→接受者。

二：UML

从上图可以看出命令模式包含如下几个角色:
Command: 抽象命令类
ConcreteCommand: 具体命令类
Invoker: 调用者
Receiver: 接收者

三：简单代码实现

四：优点

1. 降低了系统耦合度
2. 新的命令可以很容易添加到系统中去。

五：缺点

使用命令模式可能会导致某些系统有过多的具体命令类。

六：使用场景

1.系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。
2.系统需要在不同的时间指定请求、将请求排队和执行请求。
3.系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
4.系统需要将一组操作组合在一起，即支持宏命令。

七：模式总结

1. 命令模式的本质就是将命令对象进行封装打包，将发出命令的责任和执行命令的责任进行割开。

2. 命令模式中发送者只需要知道如何发送请求命令，无须关心命令执行具体过程。

3. 在发送者和接收者两者间是通过命令对象进行沟通的。请求命令本身就当做一个对象在两者间进行传递，它封装了接收者和一组动作。

4. 命令模式支持撤销。

5. 命令模式队列请求和日志请求。

解释性博客：设计模式之命令模式