用三层的思想重新理解命令模式

    学习完了三层架构，也用C#和.NET中的传参、传实体的方法分别敲了登录窗体的小例子，编码时分层的意识基本上已经形成，今天偶然再次翻看《大话设计模式》时，“命令模式”让我觉得跟最近学习过的三层架构很相似，于是对其进行再次的总结。

     Firstly，之所以能够从三层架构联想到命令模式，请看下面的两个定义：

    No1.命令模式---“命令模式即实现‘行为请求者’与‘行为实现者’之间的松耦合”，借用米老师曾经对这个模式的描述就是“生产者”和“消费者”至间的松耦合。

    No2.三层架构---对于三层架构与一层或者两层架构的区别也就是三层实现了‘界面’和‘逻辑判断’以及‘数据访问’的松耦合，于是乎，“命令模式”与“三层架构”可以说都是在解耦和，只是说“三层架构”是从宏观上对整个系统架构所进行的解耦，而命令模式则是对某个功能、需求的解耦合。

     为了找到二者之间的关系，如下图所示：

                                

                                                     

         通过这两幅图片，即可看出，命令模式即是浓缩版的三层架构，这也是我学习完了三层之后对该模式的新的理解，客户端提出需求以及接收到所要得到的事件，这就类似于U层，而Invoker类，在书中被举例为“服务员”则是对Client和Command之间的一个联通，所有的逻辑判断都是通过Invoker来实现，我将其称之为“程序眼”，同时也类似于三层设计中的BLL层；而抽象和具体的Command类，以及Receiver类则是用来响应Invoker所发出的指令，相当于三层架构中的DAL层。

     于是，新旧知识结合，更好的理解了命令模式的同时也将三层架构融入到之前所编制的知识网中，而这归功于类比学习，我在想如果将三层中的Model层加到命令模式中，是不是参数的传递会得到更好的完善？以后遇到例子再说吧，先把这个想法写下来。

     除此之外，这次用新的眼光去看设计模式，发现了之前没有留意的地方，在VB.NET教学视频中，以及之前的“依赖倒转原则”所提倡的“面向接口编程”在这个模式中体现的非常好，就像上面的UML类图所示，（用书中的例子）对厨师所能执行的方法进行抽象，即通过编写接口，让具体的方法继承抽象方法，形成“具体方法类”，比如“烤鸡翅”的类，在该方法中引入厨师参数，通过客户端里预先写入的代码去制定具体的厨师可以执行哪些具体命令，这样便实现了具体的方法与方法的执行者之间的解耦，我称之为局部解耦，从而将代码写的活灵活现，而不是像烧砖头那样，烧出来什么样就是什么样，活字印刷才是我们需要的，而这一点，通过面向接口编程就能够实现。这也算是这次比较大的一点收获了。