命令模式

    在软件设计中，有这样一种需求情况。客户端或用户可能发起一些行为，但是每个行为对应的系统中的执行对象和真正的操作不是固定的，有可能动态的根据环境改变，有可能客户端在一定的范围内自由的定制。就像你买了好多的开关回到家里，这些开关在使用之前不一定被安装到哪一个房间，也不一定用来控制哪一个电器，就算安装之后，只要你开心，也可以随意的调换他们和电器之间的关系。这和上述的软件设计中的该类需求是非常相似的。

    如果不加思考，将每个客户行为与接受对象和操作编码为直接调用关系，就将二者的耦合度大大的增加了，也丧失了灵活性，如果需要改变这种关系，需要修改代码，违反开闭原则。同时，如果扩展新的操作，必须有新的行为随之创建并绑定，使类的数量成倍增加。

    本文要介绍的命令模式可以很好解决这个问题。命令模式将请求和处理解耦，他们之间没有直接的引用关系。

    命令模式：将一个请求封装为一个对象，从而让我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。

    通过定义可以看到，命令模式的实质就是将请求封装称为命令对象，用命令的发送与接收代替直接的调用。从而实现解耦。对请求的排队/记录/支持撤销，是该模式带来的可选的好处，出于这些原因也可以使用该模式。简单的结构如下：

                                

     Invoker是请求的发送者，Command是抽象命令类，ConcreteCommand是具体命令实现。Recerver是请求接收者。Invoker针对抽象命令Command设计，从而与具体的命令和命令执行者解耦。增加新功能只需增加命令与之对应，客户端注入该命令即可使用，不用做定制性的修改。

     Invoker可以不止针对Command编程，可以设计一个Queue类，包含一个Command的队列，Invoker针对这个Queue编程，即实现了命令队列。根据实际情况，可以有多个处理者处理这些命令，甚至多线程并发执行。

    撤销可以通过在命令中定义一个与excute反向的方法来实现。（撤销的实现，更多的是使用备忘录模式）

    日志记录这个设计，可以用来实现很多的功能。例如：

• 执行大量的命令前，先记录到日志文件，每执行完一个删除一个，这样可以防止执行到一半发生意外而丢失了一部分请求。
• 将所有命令存储到日志，可以用于做统计分析。也可以用来做备份，从而让系统从灾难中恢复到某个特定时间点或状态。也可以用来实现分布式系统间，状态的拷贝或同步。

    宏命令：玩过魔兽世界的人都听过用过宏这个概念。它实际上也是一种命令。只不过它相比上面的简单的命令，利用组合模式提供了一种更为复杂的命令组合和嵌套。宏命令包含了一系列的简单命令和宏命令的序列，执行的时候会遍历执行这个序列。通过递归和组合可以实现很多复杂的效果。例如在魔兽世界中，就有很多牛人利用宏命令做出了游戏设计者都没想的复杂行为。

    总结：

        优点：

• 请求发送的处理解耦
• 新增行为简单
• 请求队列、日志、宏

        缺点：

• 增加很多的命令类

        适用场景：

• 解耦
• 请求的产生、发送、处理可能需要不是同一时间发生的
• 请求者不在了，需要请求依然有效
• 需要宏命令