设计模式——命令模式

命令模式定义

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

命令模式中角色的定义

Receive接收者角色

该角色就是干活的角色，命令传递到这里是应该被执行的

public abstract class Receiver {     
	// 抽象接收者，定义每个接收者都必须完成的业务     
	public abstract void doSomething(); 
}

接收者被定义为一个抽象类，具体的接收者按业务场景的需要可能有多个。

public class ConcreteReciver1 extends Receiver{         
//每个接收者都必须处理一定的业务逻辑     
public void doSomething(){} 
} 
public class ConcreteReciver2 extends Receiver{      
//每个接收者都必须处理一定的业务逻辑     
public void doSomething(){} 
}

Command命令角色

需要执行的所有命令都在这里声明。

public abstract class Command {     
	//每个命令类都必须有一个执行命令的方法
	public abstract void execute(); 
}
public class ConcreteCommand1 extends Command {     
	//对哪个Receiver类进行命令处理     
    private Receiver receiver;      
	//构造函数传递接收者     
	public ConcreteCommand1(Receiver _receiver){             		  				 	      
		this.receiver = _receiver;
	}     
	//必须实现一个命令     
	public void execute() {             
		//业务处理             
		this.receiver.doSomething();     
	} 
}

Invoker调用者角色

接收到命令，并执行命令。

public class Invoker {     
	private Command command;          
	public void setCommand(Command _command){             		     
		this.command = _command;
	}     
	//执行命令     
	public void action(){             
		this.command.execute();     
	}
}

客户端代码

public class Client {     
	public static void main(String[] args) {             
	//首先声明调用者Invoker             
	Invoker invoker = new Invoker();             
	//定义接收者             
	Receiver receiver = new ConcreteReciver1();             
	//定义一个发送给接收者的命令             
	Command command = new ConcreteCommand1(receiver);             	
	//把命令交给调用者去执行             		
	invoker.setCommand(command);             
	invoker.action();     
	} 
}

这里举个例子:现在智能家居炒的很热，用一台手机就可以控制门、窗、灯等家电的开关，关门、开门、关窗、开窗，这些命令都可以抽象出一个命令接口，这个接口同时有两个动作，开、关。具体的开门、关门动作由门Receiver和窗Receiver来提供实现，手机在这过程中相当于一个Invoker，只负责执行人（Client）发出的命令即可。这样设计，如果要接入新的电器到这个只能家居的体系中，比如接入电视，电视自己要提供好开关功能，再加一个电视的Command实现类，就可以接入了，完全没有命令执行者修改手机Invoker的代码。这也体现了执行者Invoker对命令的实现并不关心，可以任意增删改Receiver却不用影响上层模块代码。

命令模式的优点

类间解耦

调用者角色与接收者角色之间没有任何依赖关系，调用者实现功能时只需要调用Command抽象类的execute方法，不需要连接到是哪个接收者在执行命令。

可扩展性

Command的子类可以非常容易扩展，而与调用者Invoker和高层次的模块Client不产生严重的代码耦合。

结合其他模式

命令模式可以结合责任链模式，实现命令族解析任务；结合模板方法模式，则可以减少 Command子类的膨胀问题。

命令模式的缺点

Command抽象类的子类数量将会非常庞大，如果有N个命令，则子类就会有N个，在使用之前要考虑到这个问题。

命令模式的变形

命令模式在使用时，通常可能会通过封装对高层模块隐藏命令接收者Receiver。在项目中约定的优先级最高，每一个命令对一个或多个接收者进行封装，我们可以在项目中通过有意义的类名或命令名来处理创建命令角色时，高层模块与命令接收者的耦合关系，减少了高层模块Client对命令接收者Recevier的依赖，提高系统稳定性。

	public class ConcreteCommand extends Command {
		private Receiver recevivr;
		public ConcreteCommand () {
			this.receiver = new XXXRecevier();
		}
        public void execute() {
			receiver.doSomething();
		}
	}

这样封装后，每个命令的接受者都确定了，每个命令完成单一的职责，而不是根据接收者的不同要完成不同的职责，在高层模块也不需要考虑命令的接受者是谁。但这样也有新的问题，如果同一个命令，有不同的接收者，那命令的数量会成倍增长，在使用时也要考虑到这个问题。