Command-通过命令转发接受者/Chain of Resposibility客户端调整处理函数顺序

Command模式，是在命令发出者和接受者之间插入了一个命令，命令需要接受者初始化，命令类注册给命令发出者，命令发出者直接执行命令接口抽象的Excute方法就可以了，所以命令模式只是命令的转发解耦作用；而解释器模式是将一种动作声明为命令，然后解释命令的含义，尤其是可以多个动作可以一起发出的时候。

Command UML:

抽象命令类(Command): 声明执行操作的接口。调用接收者相应的操作，以实现执行的方法Execute。

具体命令类(ConcreteCommand): 创建一个具体命令对象并设定它的接收者。通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。 

调用者(Invoker): 要求该命令执行这个请求。通常会持有命令对象，可以持有很多的命令对象。

接收者(Receiver): 知道如何实施与执行一个请求相关的操作。任何类都可能作为一个接收者,只要它能够实现命令要求实现的相应功能。 

客户类(Client): 创建具体的命令对象，并且设置命令对象的接收者。真正使用命令的客户端是从Invoker来触发执行。

命令还 可以和组合模式结合，产生组合命令，也就是客户端可以创建一个组合命令类，使用组合命令处理类一下子对多个命令进行处理；也可以选择组合命令里面的一个命令进行处理：

Command模式优点：

1) 降低系统的耦合度:Command模式将调用操作的对象与知道如何实现该操作的对象解耦。

2) Command是头等的对象。它们可像其他的对象一样被操纵和扩展。

3) 组合命令:你可将多个命令装配成一个组合命令，即可以比较容易地设计一个命令队列和宏命令。一般说来，组合命令是Composite模式的一个实例。

4) 增加新的Command很容易，因为这无需改变已有的类。

5）可以方便地实现对请求的Undo和Redo。

命令模式的缺点：

使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类，因此某些系统可能需要大量具体命令类，这将影响命令模式的使用。

命令模式在一个命令，对应一个确定的命令处理类，很有用。Chain of Resposibility却是不确定的命令处理类，需要按照顺序来传递请求命令。

Chain of Resposibility模式，Chain of Resposibility是抽象出Handle基类，拥有设置下一个处理者函数（由客户设置），有当前的处理函数，处理不了就交给下一任，也可以有默认处理函数全部处理不了就交给它，Chain of Resposibility和状态模式的区别是状态子类之间是知道对方的且有状态管理类，但是Chain of Resposibility子类之间不知道对方且没有管理类(也可以抽取出来），只有客户端知道下一任处理者是谁(客户端需要处理调整责任链顺序）。Interpreter是区分叶子节点和枝节点，且都是可以解释文本内容的（Interpreter是一个内容多个解释器，Chain of Resposibility是一个内容一个处理类），Interpreter不拥有默认解释者。

Chain of Resposibility UML:

责任链模式优点是可以通过客户端灵活调整责任链的顺序，比State状态模式更简单灵活；缺点是可能有得不到处理的请求，可以提供默认的请求处理或者打印错误警告Log。

责任链模式，在UI引擎中广泛使用，以用特定的消息处理类处理特定的消息。