《设计模式-可复用面向对象软件的基础》学习笔记

有理解or代码不对的地方请指出。

对象行为型模式之一，名称有很多Command,Action,Transaction…..

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

动机：

如果没法联网又想玩dota，只好和电脑AI自娱自乐下。

实现：

我们可以给AI下达各种命令，如去打Roshan，集合，去捡神符等等。

这些命令应该有同一个父类Command。

class Command {

public:

virtual ~Command() {}

virtual void execute() = 0;//执行该语句意味着执行命令

protected:

Command() {}

};

对于不能被取消（相对于取消操作来讲，后面再说），不需要参数的命令，使用C++模板来实现。因此ConcreteCommand的实现为：

template<class Receiver>

class SimpleCommand : public Command {

public:

typedef void (Receiver::*Action)();

SimpleCommand(Receiver* r, Action a) :

mReceiver(r), mAction(a)

{

}

virtual void execute() 

{

(mReceiver->*mAction)();

}

private:

Action mAction;

Receiver *mReceiver;

};

Receiver即具体的接收者，也就是真正在执行命令的类，我们定义为DotaAI：

class DotaAI {

public:

virtual void attackRoshan() 

{

cout << "Let's attack BOSS!" << endl;

}

virtual void assemble()

{

cout << "Assemble,warriors!" << endl;

}

};

调用类就很简单了，比如：

class GamePlayer {

public:

void play()

{

DotaAI *vigoss = new DotaAI;

Command *c;

c = new SimpleCommand<DotaAI>(vigoss, &DotaAI::attackRoshan);

c->execute();

delete c;

c = new SimpleCommand<DotaAI>(vigoss, &DotaAI::assemble);

c->execute();

delete c;

delete vigoss;

}

};

在main函数里new一个该类的对象，调用其play接口。

运行：

Let's attack BOSS!

Assemble,warriors!

没有问题。

这是比较简单的一种情形。Command有一个公共的接口，使得你可以用同一种方式调用所有的事务。同时使用该模式也易于添加新事务以扩展系统。

如果AI的接口已经给的非常全面，那么此时比如增加新的命令如DefenseCommand等，只需要增加新的command类即可。

或者如果当有新的AI的算法时，只要重新生成AI的指针来就可以了（只要新写一个继承自DotaAI的AI类，实现其attackRoshan，assemble虚函数即可）。

其实写到这里就有一个疑问了？

我直接在Play里调用vigoss->attackRoshan(),vigoss->assemble()不是更简单，更直接么？

主要考虑到这种情况：

有时必须想某对象提交请求，但并不知道关于被请求的操作或请求的接收者的任何信息。而Command类直到，它的execute（）接口会调用正确的类（Receiver）的方法。

相对于我们这个例子，

1. 如果命令除了AI外，比如命令动物信使而不是AI送东西的，同样可以用Command的子类实现，而对外则统一位Command 接口。

即将调用操作的对象与知道如何实现该操作的对象解耦。

2. 如果vigoss并不是在Play（）里new出来的，而Command有其指针的情况

此时Client里无法直接去调用DotaAI的方法。

3. 可以将多个命令复合为一个命令，比如说DotaAI还有其他一些方法：回城守护古树，去近卫打野怪，去买侦查守卫等，那么我可以这样去写：

class AttackRoshanCommand : public Command {

public:

…

void execute()

{ mAI->buyObserveGuard();

mAI->assemble();

mAI->attackRoshan();

mAI->teleport();

}

也就是说对DotaAI给出的接口在ConcreteCommand里再次DIY一次，规划你的战术。或者像书里提到的MacroCommand类，用于管理一个子命令序列。

这也是实现Command模式时应当考虑的问题之一：

一个命令对象应该达到何种智能程度。

一个极端是它仅确定一个接收者和执行该请求的动作。另一极端是它自己实现所有功能，根本不需要额外的接收者对象。

书里还提到另外还有几个问题，有一个是支持取消和重做，即undo和redo。这需要Command提供方法逆转（reverse）它们操作的执行，首先修改Command类，增加一个virtual Unexecute()，当然不用是纯虚的，因为有的命令不用被取消。

考虑下dota里的神符，会使AI获得几种不同的状态（加速，隐身等等），于是我们在DotaAI里加上该属性和相对应的get，set方法。

同时写一个新的类:

class ChangeStateCommand : public Command {

public:

ChangeStateCommand(DotaAI *ai, DotaAI::State s=DotaAI::INVALID) :

mAI(ai),

mState(s)

{

}

virtual void execute()

{

if (mState==DotaAI::INVALID) {

srand(time(NULL));

mState = static_cast<DotaAI::State>(rand()%6);

}

mLastState = mAI->getState();

mAI->setState(mState);

mAI->printState();

}

virtual void unExecute()

{

mAI->setState(mLastState);

mAI->printState();

}

private:

DotaAI *mAI;

DotaAI::State mState;

DotaAI::State mLastState;

};

DotaAI本身不会提供返回上一个状态的接口，不过我们可以在Command里实现（Command模式的优点）。

mLast用于记录上一状态。如果需要撤销多次，可能就需要一个列表或者栈之类的来实现了。但无论如何，按照Command设计模式，这些代码很自然的就完成了。而不用一直要去想每个类的关系，职责等等（当然在许多模式里选择Command模式的时候是要去思考的）。但一旦选定之后，代码就容易编写多了。

附件为实例代码。 /Files/izualzhy/commandDesignPattern.rar