java设计模式之设计原则⑤迪米特原则

定义：
（1）一个对象应该对其他对象保持最少的了解。又叫最少知道原则
（2）尽量降低类与类之间的耦合
（3）强调只和朋友交流，不和陌生人说话（意思就是对外部引入的类越少越好）。
朋友：指的是出现在成员变量，方法的输入，输出参数中的类称为成员朋友类，而出现在方法体内部的类则不属于朋友类。

优点：
降低类之间的耦合

如果过分的使用迪米特原则会产生大量的中介类，导致系统变复杂，为维护带来难度，所以我们在使用迪米特的时候应该反复权衡，既要结构清晰，又要做到低耦合，高内聚 。
比如在我们开发中遇到一个这样的情况，有这么一个方法，我们可以把它放到A类，也可以把它放到B类，那这种情况应该怎么做呢？
我们可以坚持一个原则：如果一个方法放到本类中，既不增加类间关系，也对本类不产生负面影响，我们就可以放到本类中。

以下通过案例进行理解迪米特原则：
那我们现在有这么一个场景：有一个课程网的大老板在这一天对一个Team说查一下到现在为止线上有多少个课程，那这里面呢关系到的类Boss，TeamLeader还有课程Course。

创建TeamLeader类，里面有个checkNumberOfCourses方法，参数是课程的集合，输出课程的数量

创建Boss类，有一个查课程数量的方法，参数是TeamLeader，意思是叫TeamLeader查一下课程的数量

然后写一个测试类Test

这样案例就演示完了，我们分析一下看有没有可以优化改进的地方。
我们看Boss中的方法

迪米特原则是只和直接的朋友交流，而在这个方法中，teamLeader作为入参，它是直接的朋友，朋友的定义就是直接出现在类成员变量里，而方法体内部的类不算朋友，例如Course这个类就不是Boss的朋友，Boss直接给TeamLeader下指令，TeamLeader直接把结果给Boss就可以了，Boss不需要关注Course这个类，不应该和Course交流，那目前的这种写法就违背了迪米特原则

类图如下：

如上图所示Course这个类应该是由TeamLeader创建的而不是由Boss创建，所以我们现在应该修改一下实现，修改Boss和TeamLeader类


修改之后可以清晰的看出Boss类给TeamLeader类下指令，TeamLeader类直接查，Boss不需要了解课程类，然后TeamLeader类去跟Course类发生接触。
类图如下：

Course是由TeamLeader生成的，不再与Boss发生接触，Boss也不需要知道Course。

对于迪米特原则，主要的是要可以分清楚那些是类的朋友，哪些不是。