代码说明

l         在代码实例中，我们只考虑了防止请求过频的控制，并且也没有考虑客户端和服务端通讯的行为，在实际操作中并不会这么做。

l         Man类是接受者角色，它负责请求的具体实施。

l         GameCommand类是抽象命令角色，它定义了统一的命令执行接口。

l         MoveXXX类型是具体命令角色，它们负责执行接受者对象中的具体方法。从这里可以看出，有了命令角色，发送者无需知道接受者的任何接口。

l         Server类是调用者角色，相当于一个命令的大管家，在合适的时候去调用命令接口。

何时采用

       有如下的需求可以考虑命令模式：

l         命令的发起人和命令的接收人有不同的生命周期。比如，下遗嘱的这种行为就是命令模式，一般来说遗嘱执行的时候命令的发起人已经死亡，命令是否得到有效的执行需要靠律师去做的。

l         希望能让命令具有对象的性质。比如，希望命令能保存以实现撤销；希望命令能保存以实现队列化操作。撤销的行为在GUI中非常常见，队列化命令在网络操作中也非常常见。

l         把命令提升到类的层次后我们对类行为的扩展就会灵活很多，别的不说，我们可以把一些创建型模式和结构型模式与命令模式结合使用。

实现要点

l         从活动序列上来说通常是这样的一个过程：客户端指定一个命令的接受者；客户端创建一个具体的命令对象，并且告知接受者；客户端通过调用者对象来执行具体命令；调用者对象在合适的时候发出命令的执行指令；具体命令对象调用命令接受者的方法来落实命令的执行。

l         命令模式从结构上说变化非常多，要点就是一个抽象命令接口。抽象命令接口包含两个含义，一是把方法提升到类的层次，二是使用统一的接口来执行命令。

l         有了前面说的这个前提，我们才可以在调用者角色中做很多事情。比如，延迟命令的执行、为执行的命令记录日志、撤销执行的命令等等。

l         在应用的过程中可以省略一些不重要的角色。比如，如果只有一个执行者或者执行的逻辑非常简单的话，可以把执行的逻辑合并到具体命令角色中；如果我们并不需要使用调用者来做额外的功能，仅仅是希望通过命令模式来解除客户端和接受者之间耦合的话可以省略调用者角色。

l         如果需要实现类似于宏命令的命令组可以使用组合模式来封装具体命令。

l         如果需要实现undo操作，那么命令接受者通常也需要公开undo的接口。在应用中，undo操作往往不是调用一下undo方法这么简单，因为一个操作执行后所改变的环境往往是复杂的。

注意事项

l         不要被命令模式复杂的结构所迷惑，如果你不能理解的话请思考这句话“把方法提升到类的层次的好处也就是命令模式的好处”。

l         和把状态或算法提到类的层次的状态模式或策略模式相比，命令模式可能会产生更多的类或对象。