前言

一些及时战略游戏RTS 会用到命令模式，当有需求的一些功能是可以新增，删除，调度类型的，如兵营的出兵功能，我们点击按钮生成士兵，（生成士兵命令），还可以手动取消，连续施加出命令。这时就可以使用到命令模式（Command）

GOF对于命令模式的定义如下：
将请求封装成为对象，让你可以将客户端的不同请求参数化，并配合队列，记录，复原等方法来执行请求的操作

再见定义简单分为两本部分
请求的封装
请求的操作

请求的封装

一般来说执行一个按钮的功能时，会执行一个类的方法，而这个类的方法需要参数
当要传入的参数过多时，会造成参数行也会增多。
因此为了方便阅读，通常会建议将这些参数行设置以一个类加以封装

将调用功能时所需要的参数加以封装，就是“请求的封装”。如果以餐厅点餐的例子来看，
请求的封装就如同前台服务员将客人的点餐内容写在点餐单上。

如果将“封装”的操作再进一步，也就是连同要调用的功能执行端一起封装进来

请求的操作

当请求可以被封装成一个对象时，那么这个请求对象就可以被操作

储存：可以将“请求对象”放入一个“数据结构”中进行排序、排队、搬移、删除、暂缓执行等记录

记录:当一个请求对象被执行后，可以先不删除，将其移入“已执行”数据容器内。通过查看
“已执行”数据容器的内容，就可以知道系统过去执行命令的流程和轨迹

复原：延续上一项记录功能，若系统针对每项命令实现了“反向”操作时，可以将已执行的请求复用，这在大部分的文字编辑柔软件和绘图软件中是很常见的。

命令模式在实现上的弹性非常大，也出现许多变化的形式。在实际分析时，可以着重在“命令对象” 和“操作行为” 加以分析

训练命令的实现

分析《P级阵地》对于兵营命令的需求如下：
每个兵营都有自己的等级一级可训练的兵种，必须按照不同兵营，下达不同的命令。
有“训练时间”的功能，所以每一个训练命令都会先被暂存而不是马上被执行。
可以对兵营下达多个训练命令，所以会有多个命令同时存在必须被保存的需求。
取消训练来减少训练命令发出的数量。

执行训练命令的界面（ITrainCommand）

public abstract class ITrainCommand{
    public abstruct void Execute();
}

训练界面只定义了一个操作方法，Execute执行命令。后续从ITrainCommand延生出一个子类
TrainSoldierCommand，用来封装训练玩家阵营角色的命令。

训练Soldier命令

public class TrainSoldierCommand:ITrainCommand
{
    Enum_Soldier m_emSoldier; //兵种
    Enum_Weapon m_emWeapon; //使用的武器
    int m_Lv; //等级
    Vector3 m_position //出现的位置

    public TrainSoldierCommand(ENUM_Soldier emSoldier,ENUM_Weapon emWeapon,int Lv,Vector3 position){
        m_emSoldier = emSoldier;
        m_emWeapon = emWeapon;
        m_Lv = Lv,
        m_position = Position;
    }
    public override void Execute(){
        //产生Soldier
        ICharacterFactory Factory = PBDFactory.GetCharacterFactory();
        ISoldier Soldier = Factory.CreateSoldier(m_emSoldier,m_emWeapon,m_Lv,m_position);
    }
}

Soldier训练命令类中，将产生玩家角色时所需的参数设置为类成员，并在命令被产生时就全部指定。
而TrainSoldierCommand的“功能执行类”就是角色工厂这些参数在执行命令方法中，被当成参数传入角色工厂类的方法中，执行产生角色的功能。

兵营界面ICamp

在同时担任“命令管理者”的兵营类中，使用List泛型容器来暂存训练命令：

public absract class ICamp{
    //训练命令
    protected List<ITrainCommand> m_TrainCommand = new List<ITrainCommand>();
    protected float m_CommandTimer = 0;//当前冷却剩余时间
    protected float m_TrainCoolDown = 0;//冷却时间。

    //新增训练命令
    protected void AddTrainCommand(ITrainCommand Command){
        m_TrainCommand.Add(Command);
    }

    //删除训练命令
    public void RemoveLastTrainCommand(){
        if(m_TrainCommand.Count == 0) {
            return;
        }
        m_TrainCommands.RemoveAt(m_TrainCommands.Count-1);
    }

    //当前训练命令数量
    public void GetTrainCommandCount(){
        return m_TrainCommands.Count;
    }

    //执行命令
    public void RunCommand(){
        //没有命令，则不执行
        if(m_TrainCommands.Count == 0)
            return ;
        //冷却时间是否到了
        m_CommandTimer -= Time.deltaTime;
        if(m_CommandTimer > 0)
            return;
        m_CommandTimer = m_TrainCoolDown;

        //执行第一个命令
        m_TrainCommands[0].Execute();

        //删除
        m_TrainCommands.RemoveAt(0);
    }
}

除了新增的命令管理容器之外，另外新增了4个命令管理容器有关的操作方法供客户端使用。
在执行命令方法中，会先判断当前训练的冷却时间到了与否，如果到了，则执行命令管理器的
第一个命令，执行完成后就从命令管理器中删除。

兵营系统

定期调用每一个兵营ICamp类的RunCommand方法，则由兵营系统的定时更新来负责：

public class CampSystem:IGameSystem{
    private Dictionary<ENUM_Soldier,ICamp> m_SoldierCamps = new Dictionary<ENUM_Soldier,ICamp>();
}

public override void Update(){
    //兵营执行命令
    foreach(SoldierCamp Camp in m_SoldierCamps.Values)
        Camp.RunCommand();
}

训练命令的产生点，则由兵营类来负责

public class SoldierCamp : ICamp{
    Const int MAX_LV = 3;
    ENUM_Weapon m_emWeapon = ENUM_Weapon.Gun;
    int m_Lv = 1;
    Vectory m_position;
    //...
    //训练Soldier
    public override void Train(){
        //产生一个训练命令
        TrainSoldierCommand NewCommand = new TrainSoldierCommand(m_emSoldie,m_emWeapon,m_Lv,m_position);
        //父类公有方法直接调用
        AddTrainCommand(NewCommand);
    }
}

在训练Soldier的Train方法中，直接产生一个训练Soldier单位（Train SoldierCommand）的命令对象，并以当前兵营记录的状态设置命令的参数属性；
最后利用父类定义的增加训练命令AddTrainCommand方法，将命令加入父类ICamp的命令管理器中，并等待系统的调用来执行命令。

最后，在兵营界面CampInfoUI中，将“训练按钮”和“取消训练按钮”的监听函数，设置为调用Soldier兵营界面（SoldieCamp）中对应的“训练方法”和“取消训练的方法”，来完成整个玩家通过界面下达训练作战单位的命令流程：

public class CampInfoUI: IUserInterface{
    private ICamp m_Camp = null;//显示的兵营

    ...
    //训练
    private void OnTrainBtnClick(){
        int cost = mCamp.GetTrainCost();
        if(CheckRule(Cost > 0,"无法训练") == false)
            return;
        //是否足够
        string Msg = string.Format("AP不足无法训练，需要{0}点AP",Cost);
        if(CheckRule(m_PBDGame.CostAP(Cost),Msg) == false)
            return;
        //产生训练命令
        m_Camp.Train();
        ShowInfo(m_Camp);

    }

    priavte void OnCancelBtnClick(){
        //取消训练命令
        m_Camp.RemoveLastTrainComman();
        ShowInfo(m_Camp);
    }

}

实现需要注意

命令模式并不难理解与实现，但在实现上仍需要多方面考虑

有些时候并不需要使用命令模式来封装
如：可以直接就执行，无需等待，返回的命令

不运用命令模式的主要原因在于：
类过多，每个命令都需要封装，大量的类会造成项目不易维护的问题
请求对象并不需要被管理，也就是上面所说的立即执行的功能

需要实现大量请求命令时的应用方式
使用注册回调函数，将所有命令以管理容器组织起来，对每一个命令注册层一个回调函数，并将“功能执行者” 改为一个函数，而非类对象。最后将多个相同功能的回调函数以一个类封装在一起。

使用泛型，将“功能执行者”定义为泛型类，命令执行调用时泛型类中的“固定方法”。但以这种方式实现时，限制比较大，必须每个命令可以封装的参数个数；而且封装参数名称比较不直观，方法名也不容易与实际功能联想。如果系统中的每个命令都很“单纯”时，使用泛型设计可以省去重复定义类或回调函数的麻烦。

扩展

命令模式也可以用来为策划做一些测试命令，来实现测试（极限测试），如同一些游戏秘籍一样，直接实现某些功能。

实现网络在线游戏时，有些数据封包的管理，可能不会实现撤销操作，而侧重于执行和记录上，通过记录可以了解玩家在操作游戏时的行为，另外也有防黑客预警的作用。