行为型-命令模式

 定义

在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，实现二者之间的松耦合。这就是命令模式（Command Pattern）

 

UML

 

Command：定义命令的接口，声明执行的方法。

ConcreteCommand：命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。

Receiver：接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。

Invoker：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。

Client：创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者，或许，把这个Client称为装配者会更好理解，因为真正使用命令的客户端是从Invoker来触发执行。

 

 

 实例解析

其实曾经写过一个非常规的命令模式的实例，类似于日志记录，程序发出将日志以及参数记录到数据库的命令后，继续往下执行，不管这个命令自己是如何将日志记录到数据库，但是并未用到UNL中的那些角色，而是使用线程将将参数传给线程后，由线程池完成剩下的工作。我不知道是否为命令模式，但是理念上又有类似，个人觉得学完各模式之后也应该学会灵活应用。

电视机遥控器：

电视机是请求的接收者，遥控器是请求的发送者，遥控器上有一些按钮，不同的按钮对应电视机的不同操作。抽象命令角色由一个命令接口来扮演，有三个具体的命令类实现了抽象命令接口，这三个具体命令类分别代表三种操作：打开电视机、关闭电视机和切换频道。显然，电视机遥控器就是一个典型的命令模式应用实例。

 

//命令接收者
public class Tv {
　public int currentCh[1] annel = 0;　
public void turnOn() {　
 System.out.println("The televisino is on.");
　}　
public void turnOff() {　
 System.out.println("The television is off.");
　}　
public void changeChannel(int channel) {
　 this.currentChannel = channel;　 
System.out.println("Now TV channel is " + channel);　}
}
//执行命令的接口
public interface Command {　void execute();}
//开机命令
public class CommandOn implements Command {
　private Tv myTv;　
public CommandOn(Tv tv) {　
 myTv = tv;　
}　
public void execute() {　
 myTv.turnOn();　}
}
//关机命令
public class CommandOff implements Command {　private Tv myTv;　public CommandOff(Tv tv) {　 myTv = tv;　}　public void execute() {　 myTv.turnOff();　}}
//频道切换命令
public class CommandChange implements Command {　private Tv myTv;　private int channel;　public CommandChange(Tv tv, int channel) {　 myTv = tv; 　 this.channel = channel;　}　public void execute() {　 myTv.changeChannel(channel);　}}
//可以看作是遥控器吧
public class Control {　
private Command onCommand, offCommand, changeChannel;　
public Control(Command on, Command off, Command channel) { 
　 onCommand = on; 　 offCommand = off;　 changeChannel = channel;　}　
public void turnOn() {　
 onCommand.execute();
　}
　public void turnOff() {　
 offCommand.execute();　
}　
public void changeChannel() { 
　 changeChannel.execute();　}
}
//测试类
public class Client {　public static void main(String[] args) { 
　 // 命令接收者 　 Tv myTv = new Tv(); 　
 // 开机命令 　 CommandOn on = new CommandOn(myTv); 
　 // 关机命令 　 CommandOff off = new CommandOff(myTv); 　 
// 频道切换命令 　 CommandChange channel = new CommandChange(myTv, 2); 　
 // 命令控制对象　 Control control = new Control(on, off, channel); 　
 // 开机 　 control.turnOn(); 　 
// 切换频道 　 control.changeChannel(); 　
 // 关机 　 control.turnOff();　}}

 通过代码我们可以看到，当我们调用时，执行的时序首先是调用者类，然后是命令类，最后是接收者类。也就是说一条命令的执行被分成了三步，它的耦合度要比把所有的操作都封装到一个类中要低的多，而这也正是命令模式的精髓所在：把命令的调用者与执行者分开，使双方不必关心对方是如何操作的。

 

4模式分析

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

2.每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。

3.命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。

4.命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。

5.命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。

 

优点

1.降低对象之间的耦合度，每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。

2.新的命令可以很容易地加入到系统中。命令模式的扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。比如，文件的操作中，我们需要增加一个剪切文件的命令，则只需要把复制文件和删除文件这两个命令组合一下就行了，非常方便。

3.可以比较容易地设计一个组合命令。

4.调用同一方法实现不同的功能。

 

缺点

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

适用环境

对于大多数请求-响应模式的功能，比较适合使用命令模式，正如命令模式定义说的那样，命令模式对实现记录日志、撤销操作等功能比较方便。常见应用：1、工作队列，线程池，日程安排2、日志请求(系统恢复)

 

以上大部分摘自百度百科