设计模式——命令模式

　　将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

命令模式类图中的基本结构：

　　Command类：是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute方法用来执行命令。
　　ConcreteCommand类：Command类的实现类，对抽象类中声明的方法进行实现。
　　Client类：最终的客户端调用类。
　　Invoker类：调用者，负责调用命令。
　　Receiver类：接收者，负责接收命令并且执行命令。

优点

　　1、封装性很好：每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。
　　2、扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。

缺点

　　命令如果很多，开发起来就要头疼了。特别是很多简单的命令，实现起来就几行代码的事，而使用命令模式的话，不用管命令多简单，都需要写一个命令类来封装。

适用场景

　　对于大多数请求-响应模式的功能，比较适合使用命令模式，正如命令模式定义说的那样，命令模式对实现记录日志、撤销操作等功能比较方便。

实现

　　由于自己也不理解这个模式，暂且做个记录。照着别人的搬过来了。类图如下：

package com.lidaming.design19.command;

public class Client {
public static void main(String[] args) {
Receiver receiver = new Receiver();
ConcreteCommand command = new ConcreteCommand(receiver);

Invoker invoker = new Invoker();
invoker.setCommand(command);
invoker.doCommand();
}
}

View Code
参考
http://blog.csdn.net/zhengzhb/article/details/7550895 http://www.cnblogs.com/devinzhang/archive/2012/01/06/2315235.html