设计原则利剑五--迪米特法则

英文名称：Law of Demeter(Lod),或者最少知识原则(Least Knowledge Principle)

中文名称：迪米特法则

作      用：其核心观点就是类见解耦，弱耦合，使得理解与执行都简洁便利

深刻理解：一个对象应该对其他对象有最少的了解，并且一个对象应该尽量减少对外公布接口，犹如公司架构，CEO直接领导总监，总监直接领导经理，经理直接领导普通员工，每个角色都有各自的接口，CEO不需要直接对普通员工发出指令也没有必要，只有这样公司架构才能够稳定，才能够执行快，其中包括了4个层次的含义

            1、只和朋友交流，也就是在类设计的时候，一定要注意只与自己有关系的类进行沟通，如果出现在成员变量，方法的输入输出参数中，那么我们可以将这个类定义为我的朋友，否则，尽量不要用其他类

            2、朋友间也是有距离的，在类的设计的时候，要尽量使借口操作简单，能放在内部完成的工作一定要在本类中完成，而不是让你的朋友进行一步一步的操作，如CEO要购买一个电脑，总监下达指令买电脑过来，然后提交给他就行，不要买什么牌子，买什么价格，买多重的，让谁去买，在什么地方去买都需要CEO来进行操作，完全没有必要，只需要一个简单的借口就行，所以在定义public方法的时候，一定要慎重再慎重

            3、是自己的就是自己的，这就相当于工作职责的划分，需要电脑是CEO的事情，买什么价位的决定是总监的事情，让谁去买时经理的事情，买什么牌子是网管的事情，如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放在本类中，如果方法会增加类之间的关系，那么久要考虑放在这里是否恰当，就好像要让CEO决定买什么品牌的电脑一样，CEO要去问总监什么价位的性能合适，还要问经理谁懂电脑行情，最后还要问网管什么牌子的电脑好，这个决定买什么品牌的方法放在CEO类中是绝对不合适的。当然这个也只是一个简单的比喻，可能不太恰当，理解事情的真谛就行。

            4、谨慎使用Serializable

理论实践：

           理解了上面这么多，觉得用简单点的话语概述为：接口尽量少，方法中不要引用到没有与本类发生关系的类         

           来看看一个老师让体育委员清点女生数量的案例，在下面的设计方案中，老师与女生类之间有关系，这种设计非常的不合理，根据迪米特法则，一定不要在方法中使用不是朋友的类，否则会让类的结构复杂难以处理，为何这个老师不轻松一点，根本就不去管女生，而直接发一个指令给体育委员统计数据就行呢？先看看这个不合理的设计图：

        明显上面的设计非常差劲，让我们看看下面的设计，老师不再与女生发生关系，多简洁。

       迪米特法则还是让我想起了CEO要买电脑的案例，如下图所示，试想想如果CEO要想指定**人去买**电脑，那将会是多么负责的一个工程，这个UML图将会是多么的复杂，我不敢想象