迪米特法则

迪米特法则

迪米特法则（LoD）也叫最少知道法则：一个对象应该对其他对象有最少的了解。

1.只和朋友交流

迪米特法则还有一个英文解释是：Only talk to your immediate friends(只和直接的朋友交流)。每个对象都必然会与其他对象耦合，两个对象的耦合就成为朋友关系。下面我们通过体育课老师让班长清点女生人数为例讲解。

首先设计程序的类图：

编码实现：

程序开发完了，我们首先看下Teacher类有几个朋友类，首先要知道朋友类的定义：出现在成员变量、方法的输入输出参数中的类称为成员朋友类。所以Teacher类只有一个GroupLeader朋友类。根据迪米特法则，一个类只能和朋友类交流，上面的Teacher类内部却与非朋友类Girl发生了交流，这就不符合迪米特法则，破坏了程序的健壮性。

我们对类图做下修改：

修改后的代码：

再看场景类调用：

总之，就是类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象。

2.朋友间也是有距离的

我们在开发中经常有这种场景：调用一个或多个类，先执行第一个方法，然后是第二个方法，根据返回结果再看是否执行第三个方法。我们以安装某个软件为例，其类图为：

代码如下：

再看场景类调用：

程序很简单，但也存在一些问题：Wizard类把太多方法暴露给InstallSoftware类了，两者的朋友关系太亲密了，耦合关系变的异常牢固，如果要把Wizard中first方法的返回值改为Boolean类型，则要同时修改InstallSoftware类，增加了风险。因此，这种耦合是不合适的，我们需要对其优化。重构后的类图如下：

代码如下。导向类：

我们把安装步骤改为私有方法，只向外暴露一个安装方法，这样，即使修改步骤的逻辑，也只是对Wizard自己有影响，只需要修改自己的安装方法逻辑即可，其他类不会受到影响。

安装类：

一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。所以，我们开发中尽量不要对外公布太多public方法和非静态的public变量，尽量内敛。

3.是自己的就是自己的

在实际开发中经常会出现这样一种情况：一个方法放在吧本类中也可以，放在其他类中也没有错。那这时，我们只需要坚持一个原则：如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

总之，迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提升上去。

如果对你有帮助，就一键三连呗（点赞+收藏+关注），我会持续更新更多干货~~