设计模式—— 十五 ：命令模式

@

什么是命令模式？

命令模式的定义：

Encapsulate a request as an object,thereby letting you parameterize clients with different requests,queue or log requests,and support undoable operations.（将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。）

命令模式的核心在于引入了命令类，通过命令类来降低发送者和接收者的耦合度，请求发送 者只需指定一个命令对象，再通过命令对象来调用请求接收者的处理方法。

命令模式通用类图如下：

图15-1:命令模式模式通用类图

命令模式包含这么几个角色：

• Command（抽象命令）：声明需要执行的命令
• ConcreteCommand（具体命令）：实现声明的命令
• Receive（接收者）：接收者执行与请求相关的操作，它具体实现对请求的业务处理
• Invoker（调用者）：调用者即请求发送者，它通过命令对象来执行请求。

命令模式的本质是对请求进行封装，一个请求对应于一个命令，将发出命令的责任和执行命令的责任分割开。每一个命令都是一个操作：请求的一方发出请求要求执行一个操作；接收的一方收到请求，并执行相应的操作。命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求如何被接收、操作是否被执行、何时被执行，以及是怎么被执行的。

命令模式通用代码如下：

• Receiver：Receiver类实现具体的业务需求

/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 接收者
 */
public class Receiver {
	public void doSomething() {
		//具体的业务逻辑
	}
}

• 抽象的Command类：

/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 抽象的Command类
 */
public abstract class Command {
	// 每个命令类都必须有一个执行命令的方法
	public abstract void execute();
}

• 具体的Command类：根据需求，具体的命令类可以有多个：

/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 具体的命令类
 */
public class ConcreteCommand extends Command {
	// 维持一个对请求接收者对象的引用
	private Receiver receiver; 

	//构造函数传递接收者
	public ConcreteCommand(Receiver receiver) {
		this.receiver = receiver;
	}

	public void execute() {
		 // 调用请求接收者的业务处理方法doSomething()
		receiver.doSomething();
	}
}

• 调用者Invoker类：

/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 调用者
 */
public class Invoker {
	private Command command;
	
	// 设值注入
	public void setCommand(Command command) {
		this.command = command;
	}

	// 执行命令
	public void action() {
		this.command.execute();
	}
}

• 场景类：

/**
 * @author 三分恶
 * @date 2020年6月28日 
 * @description  
 */
public class Client {

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

}

为什么要用命令模式？

假设有一个这样的业务场景：一个正在开发的软件项目，分为三个组：需求组、美工组、开发组。在开发的过程中，客户需要和厂商沟通，和需求组讨论需求、和 美工讨论页面、和代码组讨论实现，告诉他们修改、删除、增加各种内容等。

使用命令模式前

上面的业务场景抽象成类图：

扫描二维码关注公众号，回复： 11386937 查看本文章

图15-2:甲方要求业务场景初始类图

根据类图进行具体的编码实现：

• Group:抽象类，定义业务：

/**
 * @author 三分恶
 * @date 2020年6月28日
 * @description 抽象Group
 */
public abstract class Group {
	// 甲乙双方分开办公，如果甲方要和某个组讨论，首先要找到这个组
	public abstract void find();

	// 要求增加功能
	public abstract void add();

	// 要求删除功能
	public abstract void delete();

	// 要求修改功能
	public abstract void change();

	// 要求给出所有的变更计划
	public abstract void plan();
}

• RequirementGroup（需求组）：

public class RequirementGroup extends Group{

	@Override
	public void find() {
		System.out.println("找到需求组...");
	}

	@Override
	public void add() {
		System.out.println("客户要求增加一项需求...");
	}

	@Override
	public void delete() {
		System.out.println("客户要求删除一项需求...");
	}

	@Override
	public void change() {
		System.out.println("客户要求修改一项需求...");
	}

	@Override
	public void plan() {
		System.out.println("客户要求需求变更计划...");
	}

}

• PageGroup（美工组）：

public class PageGroup extends Group{

	@Override
	public void find() {
		System.out.println("找到美工组...");
	}

	@Override
	public void add() {
		System.out.println("客户要求增加一个页面...");
	}

	@Override
	public void delete() {
		System.out.println("客户要求删除一个页面...");
	}

	@Override
	public void change() {
		System.out.println("客户要求改变一个页面...");
	}

	@Override
	public void plan() {
		System.out.println("客户要求页面变更计划...");
	}

}

• CodeGroup（开发组）：

public class CodeGroup extends Group{

	@Override
	public void find() {
		System.out.println("找到代码组...");
	}

	@Override
	public void add() {
		System.out.println("客户要求增加一项功能...");
	}

	@Override
	public void delete() {
		System.out.println("客户要求删除一项功能...");
	}

	@Override
	public void change() {
		System.out.println("客户要求修改一项功能...");
	}

	@Override
	public void plan() {
		System.out.println("客户要求代码变更计划...");
	}

}

• 场景类：

public class Client {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		//首先客户找到需求组说，过来谈需求，并修改
		System.out.println("-----------客户要求增加一项需求---------------"); 
		Group rg = new RequirementGroup();
		//找到需求组
		rg.find(); 
		//增加一个需求 
		rg.add(); 
		//要求变更计划 
		rg.plan();
	}

}

运行结果：

场景类中客户找到了需求组，向需求组提出了增加需求和需求变更的要求。

这样存在什么问题呢？甲方对乙方做一些要求的时候，要找到对应的组，但是不能希望甲方是非常专业的，可能提需求提到了开发组头上，要求页面变更提到了需求组头上。

使用命令模式后

这是为什么项目需要项目经理的原因之一。

甲方不管你什么需求、美工、开发，只管把项目经理叫过去，告诉项目经理他们的要求。项目经理再根据甲方的要求向各个组下达命令。对应的，就可以引入命令模式。

图15-3:甲方要求业务场景引入命令模式的类图

来看看具体的代码：

• 抽象命令类：

public abstract  class Command {
	//把三个组都定义好，子类可以直接使用 
	protected RequirementGroup rg = new RequirementGroup();   //需求组
	protected PageGroup pg = new PageGroup(); //美工组 
	protected CodeGroup cg = new CodeGroup(); //代码组 
	//只有一个方法，你要我做什么事情 
	public abstract void execute();
}

• 增加需求的命令：

public class AddRequirementCommand extends Command{

	@Override
	public void execute() {
		//找到需求组 
		super.rg.find(); 
		//增加一份需求
		super.rg.add(); 
		//给出计划 
		super.rg.plan();
	}

}

• 删除页面的命令：

public class DeletePageCommand extends Command{

	@Override
	public void execute() {
		//找到页面组 
		super.pg.find(); 
		//删除一个页面 
		super.rg.delete();
		//给出计划 
		super.rg.plan();
	}

}

• 负责人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 jingli = new Invoker();
		// 客户要求增加一项需求
		System.out.println("------------客户要求增加一项需求---------------");
		// 客户下命令
		Command command = new AddRequirementCommand();
		// 调用者接收到命令
		jingli.setCommand(command);
		// 调用者执行命令
		jingli.action();
	}
}

场景类就简单了很多，如果客户提出其它要求，如删除页面，只需要：

// 客户下命令
//Command command = new AddRequirementCommand();
Command command = new DeletePageCommand();

同样比较简单。

这样一来，客户提要求的时候，不需要知道具体谁去完成这个要求，只需求把这个要求提给项目经理即可。

高内聚的要求就被满足了。

命令模式优缺点

优点

● 类间解耦
调用者角色与接收者角色之间没有任何依赖关系，调用者实现功能时只需调用Command 抽象类的execute方法就可以，不需要了解到底是哪个接收者执行。

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

缺点

使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个对请求接收者的调 用操作都需要设计一个具体命令类，因此在某些系统中可能需要提供大量的具体命令类，这 将影响命令模式的使用。

命令模式使用场景

在以下情况下可以考虑使用命令模式：

• 系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。请求调用者 无须知道接收者的存在，也无须知道接收者是谁，接收者也无须关心何时被调用。
• 系统需要在不同的时间指定请求、将请求排队和执行请求。一个命令对象和请求的初始调 用者可以有不同的生命期，换言之，最初的请求发出者可能已经不在了，而命令对象本身仍 然是活动的，可以通过该命令对象去调用请求接收者，而无须关心请求调用者的存在性，可 以通过请求日志文件等机制来具体实现。
• 系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。

参考：

【1】：《Java设计模式之禅》
【2】：《design-pattern-java》
【3】：《研磨设计模式》