命令模式
命令模式是一种行为设计模式， 它可将请求转换为一个包含与请求相关的所有信息的独立对象。 该转换让你能根据不同的请求将方法参数化、 延迟请求执行或将其放入队列中， 且能实现可撤销操作。
模式动机
假如某个软件公司正在开发一款新的文字编辑器。一个软件小组的任务是创建一个包含多个按钮的工具栏， 并让每个按钮对应编辑器的不同操作。该小组创建了一个非常简洁的按钮类， 它不仅可用于生成工具栏上的按钮， 还可用于生成各种对话框的通用按钮。应用中的所有按钮都可以继承相同的类
尽管所有按钮看上去都很相似， 但它们可以完成不同的操作 ，比如打开、 保存、 打印和应用等。 在哪里放置这些按钮的点击处理代码呢？ 最简单的解决方案是在使用按钮的每个地方都创建大量的子类。 这些子类中包含按钮点击后必须执行的代码。
该软件小组很快就意识到这种方式有严重缺陷。 首先， 创建了大量的子类， 当每次修改基类按钮时， 都有可能需要修改所有子类的代码。 简单来说， 前端用户图形界面（GUI）代码与后端的业务逻辑中的代码耦合度过高，而业务逻辑代码的改变，会使得图形界面的代码（Button类及子类）被修改。
此外该软件小组还面临另外一个严重的问题：其仅仅负责包含这些按钮的工具栏的设计和实现，其调用的业务逻辑（比如保存、打开）是由另外一个软件小组所负责。也就是说，该软件团队并不知道最终会有哪些业务逻辑（命令）。该软件小组只是负责按钮按下，把一个请求发出去，但是按钮并不知道请求包括请求的对象，目的地等细节信息。也就是说Button类与其点击要执行的业务逻辑是分离的；但是Button要能调用业务逻辑。比如产品经理指出：对于粘贴按钮，原本设计的业务逻辑是把所有的对象都粘贴到文字编辑器中，但是现在的需求是只需要粘贴格式，不粘贴其它内容。如果选择前面的设计方式，则需要重新设计Button类（或者其子类）。但是如果把业务逻辑和Button类进行解耦，那么业务逻辑和GUI的Button类变成两个独立的类，可以独立变化而不相互影响。
这种情况还出现在多个类实现同一个功能情境下。比如：复制/粘贴文字等操作可能会在多个地方被调用。 例如用户可以点击工具栏上小小的 “复制” 按钮， 或者通过上下文菜单复制一些内容， 又或者直接使用键盘上的 Ctrl+C 。
如果不采用界面类和逻辑类之间的分离，则会导致下面的情形出现。程序最初只有工具栏， 因此可以使用按钮子类来实现各种不同操作。 换句话来说， 复制按钮CopyButton子类包含复制文字的代码是可行的。 在实现了上下文菜单、 快捷方式和其他功能后， 要么需要将操作代码复制进许多个类中， 要么需要让菜单依赖于按钮， 而后者是更糟糕的选择。
优秀的软件设计通常会将关注点进行分离， 而这往往会导致软件的分层。 最常见的例子： 一层负责用户图像界面； 另一层负责业务逻辑。 GUI 层负责在屏幕上渲染美观的图形， 捕获所有输入并显示用户和程序工作的结果。 当需要完成一些重要内容时 （比如计算月球轨道或撰写年度报告）， GUI 层则会将工作委派给业务逻辑底层。
这在代码中看上去就像这样： 一个 GUI 对象传递一些参数来调用一个业务逻辑对象。 这个过程通常被描述为一个对象发送请求给另一个对象。比如下图所示的GUI 层可以直接访问业务逻辑层。
然而，采用界面类和逻辑类之间的分离，也就是命令模式，建议
GUI 对象不直接提交这些请求。 你应该将请求的所有细节 （例如调用的对象、 方法名称和参数列表） 抽取出来组成命令类， 该类中仅包含一个用于触发请求的方法。
命令对象负责连接不同的 GUI 和业务逻辑对象。 此后， GUI 对象无需了解业务逻辑对象是否获得了请求， 也无需了解其对请求进行处理的方式。 GUI 对象触发命令即可， 命令对象会自行处理所有细节工作。
下一步是让所有命令实现相同的接口。 该接口通常只有一个没有任何参数的执行方法， 能在不和具体命令类耦合的情况下使用同一请求发送者执行不同命令。 此外还有额外的好处， 现在能在运行时切换连接至发送者的命令对象， 以此改变发送者的行为。
你可能会注意到遗漏的一块拼图——请求的参数。 GUI 对象可以给业务层对象提供一些参数。 但执行命令方法没有任何参数， 所以我们如何将请求的详情发送给接收者呢？ 答案是： 使用数据对命令进行预先配置， 或者让其能够自行获取数据。
回到文本编辑器。 应用命令模式后， 不再需要任何按钮子类来实现点击行为。 我们只需在 按钮Button基类中添加一个成员变量来存储对于命令对象的引用， 并在点击后执行该命令即可。
你需要为每个可能的操作实现一系列命令类， 并且根据按钮所需行为将命令和按钮连接起来。
其他菜单、 快捷方式或整个对话框等 GUI 元素都可以通过相同方式来实现。 当用户与 GUI 元素交互时， 与其连接的命令将会被执行。 与相同操作相关的元素将会被连接到相同的命令， 从而避免了重复代码。
最后， 命令成为了减少 GUI 和业务逻辑层之间耦合的中间层。 而这仅仅是命令模式所提供的一小部分好处！
总结来说，命令模式的动机如下：
在软件设计中，经常需要向某些对象发送请求，但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，我们只需在程序运行时指定具体的请求接收者即可，此时，可以使用命令模式来进行设计，使得请求发送者与请求接收者消除彼此之间的耦合，让对象之间的调用关系更加灵活。
命令模式可以对发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。这就是命令模式的模式动机。
模式定义
命令模式(Command Pattern)：将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。
模式结构
命令模式包含如下角色：
Command: 抽象命令类。定义命令的接口，声明执行的方法。
ConcreteCommand: 具体命令类。具体的命令，实现命令接口；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
Invoker: 调用者。要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
Receiver: 接收者。接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
Client:客户类
模式时序图
模式抽象代码分析
抽象命令类：
具体命令类：
调用者类：
被调用者：
客户端类：
模式分析
命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开。
每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。
命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。
命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。
命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。
模式实例
在本例中， 命令模式会记录已执行操作的历史记录， 以在需要时撤销操作。本例中的文字编辑器在每次用户与其互动时， 都会创建一个新的命令对象。 命令执行其行为后会被压入历史堆栈。
现在， 当程序执行撤销操作时， 它就需要从历史记录中取出最近执行的命令， 然后执行反向操作或者恢复由该命令保存的编辑器历史状态。
本例类图如下图所示。
具体代码如下：
Command.java
CopyCommand.java
PasteCommand.java
CutCommand.java
CommandHistory.java
Editor.java
Client.java
模式优点
降低系统的耦合度。
新的命令可以很容易地加入到系统中。
可以比较容易地设计一个命令队列和宏命令（组合命令）。
可以方便地实现对请求的Undo和Redo。
模式缺点
使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类，因此某些系统可能需要大量具体命令类，这将影响命令模式的使用。
模式适用环境
系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。
系统需要在不同的时间指定请求、将请求排队和执行请求。
系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
系统需要将一组操作组合在一起，即支持宏命令。
模式应用
核心Java程序库示例
java.lang.Runnable 的所有实现
javax.swing.Action 的所有实现
Struts其实就是一种将请求和呈现分离的技术，其中涉及命令模式。
Java语言使用命令模式实现AWT/Swing GUI的委派事件模型 (Delegation Event Model, DEM)。在AWT/Swing中，Frame、Button等界面组件是请求发送者，而AWT提供的事件监听器接口和事件适配器类是抽象命令接口，用户可以自己写抽象命令接口的子类来实现事件处理，即实现具体命令类，而在具体命令类中可以调用业务处理方法来实现该事件的处理。对于界面组件而言，只需要了解命令接口即可，无须关心接口的实现，组件类并不关心实际操作，而操作由用户来实现。
很多系统都提供了宏命令功能，如UNIX平台下的Shell编程，可以将多条命令封装在一个命令对象中，只需要一条简单的命令即可执行一个命令序列。
识别方法： 命令模式可以通过抽象或接口类型 （发送者） 中的行为方法来识别， 该类型调用另一个不同的抽象或接口类型 （接收者） 实现中的方法， 该实现则是在创建时由命令模式的实现封装。 命令类通常仅限于一些特殊行为。
模式扩展
1. 撤销操作
实现
抽象命令类：
具体命令类：
调用者类：
被调用类：
客户端类：
2. 宏命令又称为组合命令，它是命令模式和组合模式联用的产物。
宏命令也是一个具体命令，不过它包含了对其他命令对象的引用，在调用宏命令的execute()方法时，将递归调用它所包含的每个成员命令的execute()方法，一个宏命令的成员对象可以是简单命令，还可以继续是宏命令。执行一个宏命令将执行多个具体命令，从而实现对命令的批处理。
总结
在命令模式中，将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作模式或事务模式。
命令模式包含四个角色：抽象命令类中声明了用于执行请求的execute()等方法，通过这些方法可以调用请求接收者的相关操作；具体命令类是抽象命令类的子类，实现了在抽象命令类中声明的方法，它对应具体的接收者对象，将接收者对象的动作绑定其中；调用者即请求的发送者，又称为请求者，它通过命令对象来执行请求；接收者执行与请求相关的操作，它具体实现对请求的业务处理。
命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分割开。命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。
命令模式的主要优点在于降低系统的耦合度，增加新的命令很方便，而且可以比较容易地设计一个命令队列和宏命令，并方便地实现对请求的撤销和恢复；其主要缺点在于可能会导致某些系统有过多的具体命令类。
命令模式适用情况包括：需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互；需要在不同的时间指定请求、将请求排队和执行请求；需要支持命令的撤销操作和恢复操作，需要将一组操作组合在一起，即支持宏命令。
