前言

20160109：今天开始看命令模式，主要从概念和实现来深入理解该模式

概念理解【部分来自摘录】

通常来说，“行为请求者”与“行为实现者”是紧耦合的。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这些情况下，将“行为请求者”与“行为实现者”解耦，实现二者之间的松耦合就至关重要。命令模式是解决这类问题的一个比较好的方法。

LabVIEW中典型的生产者消费者即行为请求和行为实现，两者通过队列的方式进行解耦，以字符串的形式发送指令。但是在设计这些操作的时候，对特殊的事情检测功能无法解耦，所以很有学习的必要。

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

LabVIEW 的 AF结构就是将命令改为了一个对象，不知道是不是参考了这个的设计方法

Command定义了命令的接口

LabVIEW 中的Message类

ConcreteCommand实现Command接口，定义了具体的命令

Message的Do，实现了Command的命令

Client用于创建具体的命令并设定接收者
Invoker要求Command执行相应的请求
Receiver实施与执行一个请求，任何一个类都可能作为Receiver

abstract class Command{
        public void execute() {}
    }

通过初步编写，可以发现，程序将一个单次的命令改为了需要中间传递的命令；以前需要控制就是事件结构发送指令，然后执行具体的一段代码，现在封装后，可以复用执行的代码；

我将LightCommand设计包括了Light.on 和 Light.off，所以这种情况下，Command已经采用继承的方式进行了设计，当出现命令的增加时，与第一章的鸭子设计相同，继承会带来诸多的不一致问题，所以此处采用组合设计更加好。

原书中的设计

重新设计，功能完全一致，但是Command采用了单一的继承（利用了策略模式开发，没有用到继承的扩展性），所以后续更改也会更容易，实现了控制的解耦；总之一句话，多用组合（策略），少用继承！