【软考复习】对设计模式之---命令模式的理解

之前对于设计模式的学习总是一带而过，对于许多模式仅仅知道个名字，而对于其详细的模式思想并没有进行过多的思考与理解，对于【命令模式】就便也是如此。今天又翻看了下命令模式的相关资料，加深下理解。

定义：

Encapsulate(封装) a request as an object,there by letting you parameterize clients with different requests,queue or log requests,and support undoable operations.
把一个请求封装为一个对象，从而让你可以用不同的请求对客户端进行参数化，现实队列请求、记录日志、支持可撤销的操作。
初次看了这个定义后，感觉还是有点迷迷糊糊的，特别是这句:用不同的请求对客户端进行参数化。什么鬼东西？越读越读不懂，自己在心里都开始有点发毛了。但理智的我自己告诉自己要：静下心来静下心来。先看看用用，再来理解下也不着急。

对应类图:

解释：
  首先看下上图UML类图中的关系有哪几种（http://www.uml.org.cn/oobject/201610282.asp详解UML图之类图）。依赖(Dependency)
【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助，
所以要尽量不使用双向的互相依赖.
【代码表现】：局部变量、方法的参数或者对静态方法的调用
【箭头及指向】：带箭头的虚线，指向被使用者
如人依赖于计算机

聚合（Aggregation）
【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。
聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
【代码体现】：成员变量
【箭头及指向】：带空心菱形的实心线，菱形指向整体
如汽车依赖于轮胎

关联（Association)
【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，
丈夫与妻子关联可以是双向的，也可以是单向的。
双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量
【箭头及指向】：带普通箭头的实心线，指向被拥有者
如老师和学生可以为关联关系，一个老师可以有多个学生，一个学生又可以有多个老师

泛化（Generalization）
【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。
例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

【箭头指向】：带三角箭头的实线，箭头指向父类
如狗和动物的关系可为依赖。
那么上图的意思应该是：要在Client类里去执行Receiver类的action方法，需要依赖于一个Invoker类和一个ConcreteCommand类来完成。在Invoker内有一个用于约定执行者的公共基类Command类。ConcreteCommand类继承于Command基类,而具体的ConcreteCommand类有一个最终用于执行的某个命令的Receiver类。

个人的想法与理解:

在看了上面的类图描述后，感觉还是挺复杂的。有一点很搞不懂的就是，我明明只想去执行某个类的某一个指令就好，不是直接把那个类new出来，然后调用下它的一个方法不就行了吗？何必搞出来这么多类，有点想不通。public class Computer {
    public Computer() {
        System.out.println("BIRTH");
    }

    public void powerOn() {
        System.out.println("开机了");
    }

    public void powerOff() {
        System.out.println("关机了");
    }

    public static void main(String[] args) {
        Computer computer = new Computer();
        computer.powerOn();
    }
}就像上面这样，调用时，直接Computer computer = new Computer(); computer.powerOn();这样写，就可以了，为啥还要多构造那么多的类呢？是吧。
仔细分析了后，知道了原因：如果要去执行操作的这个类真是这么简单的话，确实这么样写就可以解决了。但在实际的开发中，可能Computer这个类又可能会包含许多的方法，在client端调用时，client类是直接依赖于执行类Computer的，而软件设计中又强调低耦合，所以直接这样写会有一些不妥的地方。另外，如果要对执行的命令进行其他操作时，如用这种简单的方法来写也会有诸多不便。故此，大神前辈们根据以往的设计经验通过总结后设计出了命令设计模式。
通过阅读了些许文档后，慢慢理解了命令模式的设计想法了。对于命令模式什么场景下适用就需要软件设计者根据以往的经验来仔细判断了。
最后，附上参考的学习资料：
http://www.cnblogs.com/JsonShare/p/7202133.html（设计模式解密（11）- 命令模式）

http://www.jb51.net/article/79500.htm（解析Java设计模式编程中命令模式的使用）