设计模式(12)>命令模式小强斋

命令模式

一. 定义

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可撤销的操作。

二. 模式的引入（项目组开发为例）

解决的问题

在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。

项目的成员分为需求组（Requirement Group，简称RG）、美工组（Page Group,简称PG）、代码组（Code Group，简称CG），总共加上项目经理正好十个人，刚开始的时候甲方还是很乐意和我们每个组探讨，比如和需求组讨论需求，和美工讨论页面，和代码组讨论实现，告诉他们修改这里，删除这里，增加这些等等，这是一种比较常见的甲乙方合作模式，甲方深入到乙方的项目开发中，我们把这个模式用类图表示一下：

项目组抽象

public abstract class Group {
	// 甲乙双方分开办公，你要和那个组讨论，你首先要找到这个组
	public abstract void find();

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

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

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

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

需求组

public class RequirementGroup extends Group {
	// 客户要求需求组过去和他们谈
	public void find() {
		System.out.println("找到需求组...");
	}

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

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

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

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

	}
}

代码组

public class CodeGroup extends Group {
	// 客户要求代码组过去和他们谈
	public void find() {
		System.out.println("找到代码组...");
	}

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

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

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

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

美工组

public class PageGroup extends Group {
	// 首先这个美工组应该被找到吧，要不你跟谁谈？
	public void find() {
		System.out.println("找到美工组...");
	}

	// 美工被要求增加一个页面
	public void add() {
		System.out.println("客户要求增加一个页面...");
	}

	// 客户要求对现有界面做修改
	public void change() {
		System.out.println("客户要求修改一个页面...");
	}

	// 甲方是老大，要求删除一些页面
	public void delete() {
		System.out.println("客户要求删除一个页面...");
	}

	// 所有的增删改那要给出计划呀
	public void plan() {
		System.out.println("客户要求页面变更计划...");
	}
}

整个项目的三个支柱都已经产生了，那看客户怎么和我们谈。客户刚刚开始给了我们一份他们自己写的一份需求，还是比较完整的，需求组根据这份需求写了一份分析说明书，客户一看要增加点需求

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

然后又过了段时间，客户说“界面多画了一个，找美工组过来谈谈”

public class Client {
	public static void main(String[] args) {
		// 首先客户找到美工组说，过来谈页面，并修改
		System.out.println("-------------客户要求删除一个页面-----------------");
		Group pg = new PageGroup();
		// 找到美工组
		pg.find();
		// 删除一个页面
		pg.delete();
		// 要求变更计划
		pg.plan();
	}
}

问题出现了，每次都是叫一个组去，布置个任务，然后出计划，次次都这样，如果让你当甲方也就是客户，你烦不烦？而且这种方式很容易出错误呀，客户把美工叫过去了，要删除，可美工说需求是这么写的，然后客户又命令需求组过去，一次次的折腾，客户也烦躁了，于是直接抓住项目经理说：

“我不管你们内部怎么安排，你就给我找个接头人，我告诉他怎么做，删除页面了，增加功能了，你们内部怎么处理，我就告诉他我要干什么就成了…”

我们把客户发出的命令定义成一个一个的对象

抽象命令（本例中直接把接收者作为命令接口的常量了，一般命令接口只有execute方法）

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

DeletePageCommand 删除页面命令

/**
 * 删除一个页面的命令
 */
public class DeletePageCommand extends Command {
	// 执行删除一个页面的命令
	public void execute() {
		// 找到页面组
		super.pg.find();
		// 删除一个页面
		super.pg.delete();
		// 给出计划
		super.pg.plan();
	}
}

AddRequirementCommand 增加需求命令

/**
 * 增加一项需求
 */
public class AddRequirementCommand extends Command {
	// 执行增加一项需求的命令
	public void execute() {
		// 找到需求组
		super.rg.find();
		// 增加一份需求
		super.rg.add();
		// 给出计划
		super.rg.plan();
	}
}

Command抽象类还可以有很多的子类，比如增加一个功能命令（AddCodeCommand），删除一份需求命令（DeleteRequirementCommand）等等，这里就不用描述了，都很简单。

Invoker 项目经理

/**
接头人的职责就是接收命令，并执行
 */
public class Invoker {
	// 什么命令
	private Command command;

	// 客户发出命令
	public void setCommand(Command command) {
		this.command = command;
	}

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

}

Client

public class Client {
	public static void main(String[] args) {
		// 定义我们的接头人 项目经理
		Invoker manager = new Invoker(); // 接头人就是项目经理
		// 客户要求增加一项需求
		System.out.println("-------------客户要求增加一项需求-----------------");
		// 客户给我们下命令来
		Command command = new AddRequirementCommand();
		// 接头人接收到命令
		manager.setCommand(command);
		// 接头人执行命令
		manager.action();
	}
}

如果客户要求删除一个页面，只需把上面的 command = new AddRequirementCommand改成DeletePageCommand即可。

public class Client {
	public static void main(String[] args) {
		// 定义我们的接头人 项目经理
		Invoker manager = new Invoker(); // 接头人就是项目经理
		// 客户要求增加一项需求
		System.out.println("-------------客户要求增加一项需求-----------------");
		// 客户给我们下命令来
		Command command = new DeletePageCommand();
		// 接头人接收到命令
		manager.setCommand(command);
		// 接头人执行命令
		manager.action();
	}
}

组合命令

客户要求增加一项需求，那是不是页面也增加，同时功能也要增加呢？如果不使用命令模式，客户就需要先找需求组，然后找美工组，然后找代码组，这个…，你想让客户跳楼呀！使用命令模式后，客户只管发命令模式，你增加一项需求，没问题，我内部调动三个组通力合作，然后反馈你结果，这也正是客户需要的，那这个要怎么修改呢？想想看，很简单的，在AddRequirementCommand类的execute方法中增加对PageGroup和CodePage的调用就成了，修改后的代码如下：

public class AddRequirementCommand extends Command {
	// 执行增加一项需求的命令
	public void execute() {
		// 找到需求组
		super.rg.find();
		// 增加一份需求
		super.rg.add();
		// 页面也要增加
		super.pg.add();
		// 功能也要增加
		super.cg.add();
		// 给出计划
		super.rg.plan();
	}
}

撤销命令

命令模式做了一层非常好的封装。那还有一个问题需要大家考虑：客户发出命令，那要是撤回怎么办？就类似你使用Ctl+Z组合键（undo功能），发出一个命令，在没有执行或执行后撤回（执行后撤回是状态变更）该怎么实现呢?想想看，简单，非常简单，undo也是一个命令嘛！

public abstract class Group {
	// 甲乙双方分开办公，你要和那个组讨论，你首先要找到这个组
	public abstract void find();

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

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

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

	// 被要求给出所有的变更计划
	public abstract void plan();
	
	// 每个接收者都要对直接执行的任务可以回滚
	public void rollback()
	{
		//根据日志进行回滚
	}
}

三. 模式解读

3.1 命令模式的类图

3.2包含的角色

抽象命令（Command）：定义命令的接口，声明执行的方法。
具体命令（ConcreteCommand）：具体命令，实现要执行的方法，它通常是“虚”的实现；通常会有接收者，并调用接收者的功能来完成命令要执行的操作。
接收者（Receiver）：真正执行命令的对象。任何类都可能成为一个接收者，只要能实现命令要求实现的相应功能。
调用者（Invoker）：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
客户端（Client）：命令由客户端来创建，并设置命令的接收者。

3.3 命令模式的实现代码

Receiver

public abstract class Receiver  {

	//每个接收者处理的业务
	public abstract void  action();
	}

ReceiverA

public class ReceiverA extends Receiver {

    public void action() {
        System.out.println("接收者A执行命令");
    }
}

ReceiverB

public class ReceiverB extends Receiver{

    public void action() {
        System.out.println("接收者B执行命令");
    }
}

Command

public interface Command {

	public abstract void execute();
}

CommandImplA

public class CommandImplA implements Command {

	private Receiver receiver;

	public CommandImplA(Receiver receiver) {
      this.receiver=receiver;
	}

	public void execute() {
		receiver.action();
	}
}

CommandImplB

public class CommandImplB implements Command {

	private Receiver receiver;

	public CommandImplB(Receiver receiver) {
      this.receiver=receiver;
	}

	public void execute() {
		receiver.action();
	}
}

Invoker

public class Invoker {

	private Command command;

	public void setCommand(Command command) {
		this.command = command;
	}

	public void execute() {
		command.execute();
	}
}

Client

public class Client
{

	public static void main(String[] args) {

		Receiver rec = new ReceiverA();
		Command cmd = new CommandImplA(rec);
		Invoker i = new Invoker();
		i.setCommand(cmd);
		i.execute();

		rec=new ReceiverB();
		cmd=new CommandImplB(rec);
		i.setCommand(cmd);
		i.execute();
	}
}

执行结果

接收者A执行命令
接收者B执行命令

3.4 模式分析

本质：对命令进行封装，将发出命令与执行命令的责任分开。
每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。
请求方和接收方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。
使请求本身成为一个对象，这个对象和其它对象一样可以被存储和传递。
命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。

四. 模式总结

4.1 优点

解除了请求者与实现者之间的耦合，降低了系统的耦合度。
对请求排队或记录请求日志，支持撤销操作。
可以容易地设计一个组合命令。
新命令可以容易地加入到系统中。

4.2 缺点

因为针对每一个命令都需要设计一个具体命令类，使用命令模式可能会导致系统有过多的具体命令类。

4.3 适用场景

当需要对行为进行“记录、撤销/重做”等处理时。
系统需要将请求者和接收者解耦，使得调用者和接收者不直接交互。
系统需要在不同时间指定请求、请求排队和执行请求。
系统需要将一组操作组合在一起，即支持宏命令。

参考：设计模式之禅

http://www.cnblogs.com/wangjq/archive/2012/07/11/2585930.html

相关阅读:
SQL-server 学习笔记（三）：实战建库建表，插入数据
 SQL-server 学习笔记（二）：约束
 SQL-server 学习笔记（一）：数据库创建
 操作系统——第五章
 操作系统——第四章
 操作系统——第三章
 操作系统——第二章（二）
Python之路，Day7
Day6
Day5
原文地址：https://www.cnblogs.com/xiaoqiangzhaitai/p/5637298.html

设计模式(12)>命令模式 小强斋