Command模式
Command模式的中心思想还是代码的解耦和，通过引入中间层来解决代码的紧耦合。
下面来看一个在日常开发中经常碰到的场景：在一个类中需要调用另一个类的实现方法，那么比较常用的开发方式如下：
package com.test.command.original;
/**
* 接受者（具体实现类）
*
*/
public class Receiver {
public void action() {
System.out.println("Original implement...");
}
}
package com.test.command.original;
/**
* 调用者
*
*/
public class Invoker {
public void execute() {
Receiver receiver = new Receiver();
receiver.action();
}
}
package com.test.command.original;
public class Test {
public static void main(String[] args) {
Invoker invoker = new Invoker();
invoker.execute();
}
}
这样在调用者中直接new一个实现类并且调用其实现方法，这就是一般情况下的使用方式。其实这种方式并没有太大问题， 但是却实现了紧耦合，在一般情况下问题不大，但是在特定情况下就会显得不那么灵活、好用。
比如：在开发过程中需要Receiver和Test（实际上就是Client）同步进行开发，而且开发过程中有可能会重命名、重构；会有很多个Receiver，同时执行方法的时候需要根据当前所有的Receiver请求先进性排序再执行，或者在Receiver中会有redo()和undo()操作。
上面提到的几种情况，如果只是用简单的代码并不容易实现，这时引入Command模式就很合适了。
定义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
类型：行为类模式
类图：
Command模式代码如下：
package com.test.command.simple;
/**
* 接受者（具体实现）
*
*/
public class Receiver {
public void action() {
System.out.println("Command implement...");
}
}
package com.test.command.simple;
/**
* 创建一个抽象类Command
*
*/
public abstract class Command {
abstract public void execute();
}
package com.test.command.simple;
/**
* Command的实现类
*
*/
public class ConcreteCommand extends Command {
//持有具体实现类的引用
Receiver receiver;
public ConcreteCommand(Receiver receiver) {
this.receiver = receiver;
}
@Override
public void execute() {
//在这里才会调用具体实现的方法，相当于在Invoker和Receiver之间又封装了一层
receiver.action();
}
}
package com.test.command.simple;
/**
* 调用者
*
*/
public class Invoker {
/*
* 在调用者中持有中间层Command的应用
* 这样具体的实现只要是继承自Command就可以，Invoker并不需要知道其实怎么实现的
*/
Command command;
public Invoker(Command command) {
this.command = command;
}
public void execute() {
command.execute();
}
}
package com.test.command.simple;
public class Test {
public static void main(String[] args) {
//首先还是要有具体实现类的对象
Receiver receiver = new Receiver();
//创建中间层的实现，并让其持有具体实现类
Command command = new ConcreteCommand(receiver);
//创建调用者的实例，并让其持有中间层Command
Invoker invoker = new Invoker(command);
//调用者来调用实现方法
invoker.execute();
}
}
之前的写法是在Invoker中直接去调用Receiver的实现方法，而Command模式则是在Invoker和Receiver之间引入了Command层，并且通过Command的实现类来调用Receiver的方法，这样在Invoker和Receiver之间就没有任何关联了，达到了解耦和的目的。
再来看之前提出的问题：
- 在开发过程中需要Receiver和Test（实际上就是Client）同步进行开发，而且开发过程中有可能会重命名、重构？
这个已经很好解决了，因为在Invoker上直接持有的是抽象类（或接口）的引用，开发者只要保证接口名不变即可。
- 会有很多个Receiver，同时执行方法的时候需要根据当前所有的Receiver请求先进性排序再执行？
由于所有的Receiver请求都是在Invoker的execute方法中统一执行的，所以可以在Invoker的execute方法记录所有传入的Command的状态，当执行execute方法时可以根据当前所有的请求做对应的排序等处理后，在同一执行Receiver的实现方法。
- 在Receiver中会有redo()和undo()操作
这就需要记录每一次的请求，在Command模式中每一次请求的状态（数据）可以记录在ConcreteCommand中，示例如下：
package com.test.command.useful;
/**
* （接收者）具体实现类
*
*/
public class Receiver {
public void execute(String name) {
System.out.println("Receiver execute...");
}
public void undo() {
System.out.println("Receiver undo...");
}
}
package com.test.command.useful;
/**
* 抽象类Command，定义了两个抽象方法：execute和undo，用于执行和取消
*
*/
public abstract class Command {
public abstract void execute(String name);
public abstract void undo();
}
package com.test.command.useful;
import java.util.ArrayList;
import java.util.List;
public class ConcreteCommand extends Command {
Receiver receiver;
//用于保存状态的list
List<String> undoList = new ArrayList<String>();
public ConcreteCommand(Receiver receiver) {
this.receiver = receiver;
}
@Override
public void execute(String name) {
receiver.execute(name);
undoList.add(name);
System.out.println("execute:" + undoList);
}
@Override
public void undo() {
if(null != undoList && undoList.size() > 0) {
undoList.remove(undoList.size() - 1);
receiver.undo();
}
System.out.println("undo:" + undoList);
}
}
package com.test.command.useful;
/**
* 请求类
*
*/
public class Invoker {
Command command;
public Invoker(Command command) {
this.command = command;
}
public void execute(String name) {
command.execute(name);
}
public void undo() {
command.undo();
}
}
package com.test.command.useful;
public class Test {
public static void main(String[] args) {
Receiver receiver = new Receiver();
Command command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker(command);
invoker.execute("Test1");
invoker.execute("Test2");
invoker.execute("Test3");
//Oh,I regret it!
invoker.undo();
}
}
从上述代码中可以看出ConcreteCommand保存了每次Receiver请求的状态，在undo的时候只需要从list中拿出需要的那一条状态即可进行相关处理，redo也同理。但是如果不使用Command模式就很难处理了，即便可以处理，代码也会显得很乱，不移维护。
从网上找了一些Command模式的应用场景，有些也不是很明白，暂时记下来，等到需要用到的时候再研究：
1 Multi-level undo（多级undo操作）
如果系统需要实现多级回退操作，这时如果所有用户的操作都以command对象的形式实现，系统可以简
单地用stack来保存最近执行的命令，如果用户需要执行undo操作，系统只需简单地popup一个最近的
command对象然后执行它的undo()方法既可。
2 Transactional behavior（原子事务行为）
借助command模式，可以简单地实现一个具有原子事务的行为。当一个事务失败时，往往需要回退到执
行前的状态，可以借助command对象保存这种状态，简单地处理回退操作。
3 Progress bars（状态条）
假如系统需要按顺序执行一系列的命令操作，如果每个command对象都提供一个
getEstimatedDuration()方法，那么系统可以简单地评估执行状态并显示出合适的状态条。
4 Wizards（导航）
通常一个使用多个wizard页面来共同完成一个简单动作。一个自然的方法是使用一个command对象来封
装wizard过程，该command对象在第一个wizard页面显示时被创建，每个wizard页面接收用户输入并设
置到该command对象中，当最后一个wizard页面用户按下“Finish”按钮时，可以简单地触发一个事件
调用execute()方法执行整个动作。通过这种方法，command类不包含任何跟用户界面有关的代码，可以
分离用户界面与具体的处理逻辑。
5 GUI buttons and menu items（GUI按钮与菜单条等等）
Swing系统里，用户可以通过工具条按钮，菜单按钮执行命令，可以用command对象来封装命令的执行。
6 Thread pools（线程池）
通常一个典型的线程池实现类可能有一个名为addTask()的public方法，用来添加一项工作任务到任务
队列中。该任务队列中的所有任务可以用command对象来封装，通常这些command对象会实现一个通用的
接口比如java.lang.Runnable。
7 Macro recording（宏纪录）
可以用command对象来封装用户的一个操作，这样系统可以简单通过队列保存一系列的command对象的状
态就可以记录用户的连续操作。这样通过执行队列中的command对象，就可以完成"Play back"操作了。
8 Networking
通过网络发送command命令到其他机器上运行。
9 Parallel Processing（并发处理）
当一个调用共享某个资源并被多个线程并发处理时。
参考：http://men4661273.iteye.com/blog/1633775
命令者模式的优点有如下几点：
1、在命令者模式中，请求者不直接与接受者互交，既请求者不包含接受者的引用，因此彻底消除了彼此之间的耦合。
2、命令者模式满足了软件的“开-闭原则”。如果增加新的具体命令和该命令的接受者，不必修改调用者的代码，调用者就可以直接使用新的命令对象。反之如果增加新的调用者，不必修改现有的具体命令和接受者。新增加的调用者就可以使用已有的具体命令
3、由于请求者的请求被封装到了具体命令中，那么就可以将具体命令保存到持久化媒介中，在需要的时候重新执行这个具体命令。因此使用命令者模式可以记录日志
4、使用命令者模式可以对请求者的请求进行排队，每个请求者各自对应一个具体命令，因此可以按一定的顺序执行这些命令。
参考：http://blog.csdn.net/qq7342272/article/details/8175405