前言
20160109： 今天开始看命令模式，主要从概念和实现来深入理解该模式
概念理解【部分来自摘录】
概念
通常来说，“行为请求者”与“行为实现者”是紧耦合的。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这些情况下，将“行为请求者”与“行为实现者”解耦，实现二者之间的松耦合就至关重要。命令模式是解决这类问题的一个比较好的方法。
LabVIEW中典型的生产者消费者即行为请求和行为实现，两者通过队列的方式进行解耦，以字符串的形式发送指令。但是在设计这些操作的时候，对特殊的事情检测功能无法解耦，所以很有学习的必要。
命令模式
命令模式将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
命令模式的结构图如下
LabVIEW 的 AF结构就是将命令改为了一个对象，不知道是不是参考了这个的设计方法
Command定义了命令的接口
LabVIEW 中的Message类
ConcreteCommand实现Command接口，定义了具体的命令
Message的Do，实现了Command的命令
Client用于创建具体的命令并设定接收者
Invoker要求Command执行相应的请求
Receiver实施与执行一个请求，任何一个类都可能作为Receiver
C#实现
Demo一 ： 设计模式中的命令模式范例
实现命令接口
abstract class Command{public void execute() {}}
实现控制
通过初步编写，可以发现，程序将一个单次的命令改为了需要中间传递的命令；以前需要控制就是事件结构发送指令，然后执行具体的一段代码，现在封装后，可以复用执行的代码；
实现遥控器
控制实现
注意的是，我这里的设计存在一个耦合问题
我将LightCommand设计包括了Light.on 和 Light.off， 所以这种情况下，Command已经采用继承的方式进行了设计，当出现命令的增加时，与第一章的鸭子设计相同，继承会带来诸多的不一致问题，所以此处采用组合设计更加好。
原书中的设计
重新设计，功能完全一致，但是Command采用了单一的继承（利用了策略模式开发，没有用到继承的扩展性），所以后续更改也会更容易，实现了控制的解耦；总之一句话，多用组合（策略），少用继承！