2.4 迪米特法则原则

2.4.1 迪米特法则定义

1987年秋天，迪米特法则由美国Northeastern University的Ian Holland提出，被UML的创始者之一Booch等人普及。后来，因为经典著作The Pragmatic Programmer而广为人知。

迪米特法则（Law of Demeter，LoD）又称为最少知道原则（Least Knowledge Principle，LKP），是指一个对象类对于其他对象类来说，知道得越少越好。也就是说，两个类之间不要有过多的耦合关系，保持最少关联性。

迪米特法则有一句经典语录：只和朋友通信，不和陌生人说话。也就是说，有内在关联的类要内聚，没有直接关系的类要低耦合。这样的例子在我们生活中也随处可见，就像家里的水管装修，有洗衣机地漏、卫生间地漏、厨房地漏，但它们最终都汇到同一个污水处理系统里。在平常使用时，我们不会考虑这些水管是怎么关联流向的，只需要考虑最上层的使用即可。

2.4.2 模拟场景

本书通过模拟学生、老师、校长之间关系的例子来说明迪米特法则。老师需要负责具体某一个学生的学习情况，而校长会关心老师所在班级的总体成绩，不会过问具体某一个学生的学习情况。

下面模拟这样的例子，如果校长想知道一个班级的总分和平均分，是应该找老师要，还是跟每一个学生要再进行统计呢？显然是应该找具体的班主任老师。我们在实际开发时，容易忽略这样的真实情况，开发出逻辑错误的程序。

2.4.3 违背原则方案

首先定义一个学生信息类，这个类比较简单，包括学生姓名、考试排名、总分。在实际的业务开发中会更复杂，这里只是简化后的类。

之后再定义出老师类，在老师类里初始化学生的信息，以及提供基本的信息获取接口。

在老师类中初始化了学生信息，同时提供了简单的接口。接下来定义校长类，校长管理全局，并在校长类中获取学生人数、总分、平均分等。

以上就是通过校长管理所有学生，老师只提供了非常简单的信息。虽然可以查询到结果，但是违背了迪米特法则，因为校长需要了解每个学生的情况。如果所有班级都让校长类统计，代码就会变得非常臃肿，也不易于维护和扩展。

2.4.4 迪米特法则改善代码

从以上的实现方式我们发现，不该让校长直接管理学生，校长应该管理老师，由老师提供相应的学生信息查询服务。那么，接下来我们就把校长要的信息交给老师类去处理。

在使用迪米特法则后，把原来违背迪米特法则的服务接口交给老师类处理。这样每一位老师都会提供相应的功能，校长类只需要调用使用即可，而不需要了解每一位学生的分数。

接下来再看校长类是如何使用的，如下所示。

校长类直接调用老师类的接口，并获取相应的信息。这样一来，整个功能逻辑就非常清晰了。

使用单元测试验证程序结果。