5.2 Command命令模式

意图：

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

 

类图：

 Command类：是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute方法用来执行命令。

 ConcreteCommand类：Command类的实现类，对抽象类中声明的方法进行实现。

 Client类：最终的客户端调用类。

以上三个类的作用应该是比较好理解的，下面我们重点说一下Invoker类和Recevier类。

 Invoker类：调用者，负责调用命令。

 Receiver类：接收者，负责接收命令并且执行命令。

所谓对命令的封装，说白了，无非就是把一系列的操作写到一个方法中，然后供客户端调用就行了，反映到类图上，只需要一个ConcreteCommand类和Client类就可以完成对命令的封装，即使再进一步，为了增加灵活性，可以再增加一个Command类进行适当地抽象，这个调用者和接收者到底是什么作用呢？

其实大家可以换一个角度去想：假如仅仅是简单地把一些操作封装起来作为一条命令供别人调用，怎么能称为一种模式呢？命令模式作为一种行为类模式，首先要做到低耦合，耦合度低了才能提高灵活性，而加入调用者和接收者两个角色的目的也正是为此。当我们调用时，执行的时序首先是调用者类，然后是命令类，最后是接收者类。也就是说一条命令的执行被分成了三步，它的耦合度要比把所有的操作都封装到一个类中要低的多，而这也正是命令模式的精髓所在：把命令的调用者与执行者分开，使双方不必关心对方是如何操作的。

 

例子：

我们去餐厅吃饭，我们是通过服务员来点菜，具体是谁来做这些菜和他们什么时候完成的这些菜，其实我们都不知道。抽象之，“菜单请求者”我们和“菜单实现者”厨师，2者之间是松耦合的，我们对这些菜的其他一些请求比如“撤销，重做”等，我们也不知道是谁在做。其实这就是本文要说的Command模式。

 

C++代码：

#include <iostream>
#include <list>
using namespace std;

class Barbecuer
{
public:
	void BakeMutton()
	{
		cout<<"烤羊肉串"<<endl;
	}

	void BakeChickenWing()
	{
		cout<<"烤鸡翅"<<endl;
	}
};
class Command
{
protected:
	Barbecuer *receiver;
public:
	Command(Barbecuer *receiver) : receiver(receiver){} 
	virtual void ExcuteCommand() = 0;
};

class BakeMuttonCommand : public Command
{
public:
	BakeMuttonCommand(Barbecuer *receiver) : Command(receiver){}
	virtual void ExcuteCommand()
	{
		receiver->BakeMutton();
	}
};

class BakeChickenWingCommand : public Command
{
public:
	BakeChickenWingCommand(Barbecuer *receiver) : Command(receiver){}
	virtual void ExcuteCommand()
	{
		receiver->BakeChickenWing();
	}
};

class Waiter
{
private:
	list<Command*> orders;
public:
	void SetOrder(Command *command)
	{
		orders.push_back(command);
		cout<<"增加订单"<<endl;
	}

	void CancelOrder(Command *command)
	{
		orders.remove(command);
		cout<<"取消订单"<<endl;
	}

	void Notify()
	{
		list<Command*>::const_iterator iter;
		for (iter=orders.begin(); iter!=orders.end(); ++iter)
			(*iter)->ExcuteCommand();
	}

};
int main(int argc, char **argv)
{
	Barbecuer *boy = new Barbecuer();
	Command *bBakeMuttonCommand1 = new BakeMuttonCommand(boy);
	Command *bBakeMuttonCommand2 = new BakeMuttonCommand(boy);
	Command *bakeChickenWingCommand = new BakeChickenWingCommand(boy);
	Waiter *girl = new Waiter();

	girl->SetOrder(bBakeMuttonCommand1);
	girl->SetOrder(bBakeMuttonCommand2);
	girl->SetOrder(bakeChickenWingCommand);
	girl->CancelOrder(bBakeMuttonCommand1);
	
	girl->Notify();

	system("pause");
	return 0;
}

效果与实现要点：

1．Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。

2．实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。

3．通过使用Compmosite模式，可以将多个命令封装为一个“复合命令”MacroCommand。

4．Command模式与C#中的Delegate有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，更符合抽象原则；Delegate以函数签名来定义行为接口规范，更灵活，但抽象能力比较弱。

5．使用命令模式会导致某些系统有过多的具体命令类。某些系统可能需要几十个，几百个甚至几千个具体命令类，这会使命令模式在这样的系统里变得不实际。

适用性：

在下面的情况下应当考虑使用命令模式：

1．使用命令模式作为"CallBack"在面向对象系统中的替代。"CallBack"讲的便是先将一个函数登记上，然后在以后调用此函数。

2．需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。换言之，原先的请求发出者可能已经不在了，而命令对象本身仍然是活动的。这时命令的接收者可以是在本地，也可以在网络的另外一个地址。命令对象可以在串形化之后传送到另外一台机器上去。

3．系统需要支持命令的撤消(undo)。命令对象可以把状态存储起来，等到客户端需要撤销命令所产生的效果时，可以调用undo()方法，把命令所产生的效果撤销掉。命令对象还可以提供redo()方法，以供客户端在需要时，再重新实施命令效果。

4．如果一个系统要将系统中所有的数据更新到日志里，以便在系统崩溃时，可以根据日志里读回所有的数据更新命令，重新调用Execute()方法一条一条执行这些命令，从而恢复系统在崩溃前所做的数据更新。