前言 一些及时战略游戏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); } }实现需要注意 命令模式并不难理解与实现，但在实现上仍需要多方面考虑
有些时候并不需要使用命令模式来封装 如：可以直接就执行，无需等待，返回的命令
不运用命令模式的主要原因在于： 类过多，每个命令都需要封装，大量的类会造成项目不易维护的问题 请求对象并不需要被管理，也就是上面所说的立即执行的功能
需要实现大量请求命令时的应用方式 使用注册回调函数，将所有命令以管理容器组织起来，对每一个命令注册层一个回调函数，并将“功能执行者” 改为一个函数，而非类对象。最后将多个相同功能的回调函数以一个类封装在一起。
使用泛型，将“功能执行者”定义为泛型类，命令执行调用时泛型类中的“固定方法”。但以这种方式实现时，限制比较大，必须每个命令可以封装的参数个数；而且封装参数名称比较不直观，方法名也不容易与实际功能联想。如果系统中的每个命令都很“单纯”时，使用泛型设计可以省去重复定义类或回调函数的麻烦。
扩展 命令模式也可以用来为策划做一些测试命令，来实现测试（极限测试），如同一些游戏秘籍一样，直接实现某些功能。
实现网络在线游戏时，有些数据封包的管理，可能不会实现撤销操作，而侧重于执行和记录上，通过记录可以了解玩家在操作游戏时的行为，另外也有防黑客预警的作用。
