含义

英文名是 Law Of Demeter，中文名是迪米特法则，又称最小知识原则。

“迪米特”名字来源于希腊神话的农业女神，代表生命的孕育和新生。至于名字和原则有什么关系，我也没理解。硬记吧…

原文是 Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.

中文翻译过来就是：

1. 每个模块只应该了解那些与它关系密切的模块的有限知识。

2. 或者说，每个模块只和自己的朋友“说话”，不和陌生人“说话”。

它是有关模块或类之间该如何交互的一个原则。

怎么理解呢？

还有另一个说法，一个实体应尽可能少的与其他实体发生相互作用。我是读了这句话，再回过头去理解原文时才明白，原文的模块或类对应实体，实体间尽可能少交互，对应模块或类之间应尽可能少交互，必须交互的话，也只了解它的有限知识。

单从类来说明的话，就可理解成：

1. 不该有直接依赖关系的类之间，不要有依赖；

2. 有依赖关系的类之间，尽量只依赖必要的接口，接口也就是定义中的“有限知识”。

优点

这样做有什么优点呢？

1. 先说尽可能不互相依赖的优点，这得从反面来论证，即存在许多互相依赖的关系会怎样？参考密密麻麻的线路交织，感到头大吗？头大。假设 A 连接着许多 B、C、D、E、F、G…，A 一改，这一大堆被连接方很可能都需要跟着改，那如果是一两个关联关系呢，甚至没有关联关系，那就简单多了。

2. 再说只依赖有限知识，它其实和基于接口而非实现编程较为类似，那所具备的优点也类似：可减少依赖方的变化对使用者的影响，甚至让其无影响，增加可读性、灵活性(自主性)。

如何做

原则的解释其实已经说明了该如何做了。

注意：

1. 设计模块或类时，尽量少让各模块或类之间产生依赖关系。

2. 模块或类必须有依赖时，只依赖必要的有限知识，即类似于功能描述之类，而不是实现。

3. 结合实际情况，还可附加的一点是当模块或类必须依赖时，依赖也尽量是单向的。

做到上述 3 点有无辅助方式呢？

对于类来说，依赖注入可帮助实现第 2 点，类之间依赖时，只依赖接口。