迪米特法则（Law of Demeter，简称LoD）还有一个更通俗的名字叫最少知道原则（Least Knowledge Principle）。它最早诞生于1987年美国东北大学的一个研究项目，核心思想用一句话概括就是：一个对象应该对其他对象保持最少的了解。这个原则看起来简单，但在实际的类设计中非常容易被忽视，很多看似合理的链式调用其实都在悄悄增加系统的耦合度。本文将结合Java代码实例，深入讲解迪米特法则的内涵、判断标准以及落地方法。
迪米特法则的定义与核心内涵
迪米特法则的正式定义可以表述为：一个软件实体应当尽可能少地与其他实体发生相互作用。每一个软件单位对其他的单位只有最少的知识，而且局限于那些与本单位密切相关的软件单位。用更口语化的说法就是：只和你的直接朋友说话，不要跟陌生人讲话。
那么什么才算直接朋友呢？在Java中，如果一个对象出现在一个类的方法参数、方法返回值、成员变量中，这些类就是直接朋友。而如果一个类是通过局部变量得到的，也就是在方法内部new出来的，或者通过朋友的方法间接拿到的对象，那就是陌生人。迪米特法则要求我们尽量减少与陌生人的交互，每个类只依赖它真正需要了解的直接朋友。
举一个生活中的例子来理解：你去商店买东西，你只需要和店员交流，付款拿货即可，完全没有必要知道店员是怎么从仓库取货的、仓库的进货渠道是什么。如果你非要了解仓库内部流程才能买到商品，那么这个系统的设计就出了问题。软件设计同样如此，调用者只关心结果，不应该深入被调用者的内部结构去获取数据。
违反迪米特法则的典型代码分析
最常见的违反形式就是链式调用，即通过一个对象获取另一个对象，再通过这个对象获取第三个对象的方法。看下面这段Java代码：
public class Shop {
private Warehouse warehouse;
public Warehouse getWarehouse() {
return warehouse;
}
}
public class Warehouse {
private Supplier supplier;
public Supplier getSupplier() {
return supplier;
}
}
public class Supplier {
public String getContactInfo() {
return "联系人：张三，电话：13800000000";
}
}
// 客户端调用
public class Client {
public void doSomething() {
Shop shop = new Shop();
// 链式调用，层层深入内部结构
String info = shop.getWarehouse().getSupplier().getContactInfo();
System.out.println(info);
}
}这段代码编译没有任何问题，功能也能实现，但它严重违反了迪米特法则。Client类不仅知道了Shop，还知道了Shop内部有Warehouse，Warehouse内部有Supplier。一旦Warehouse和Supplier的关系发生变化，或者Supplier的getContactInfo方法改名，Client这里的代码就必须跟着修改。这种牵一发而动全身的现象，就是类之间耦合过高的直接体现。
更隐蔽的问题是，这种依赖关系在编译期就被固化了。假设某天Shop不再持有Warehouse而是采用代发货模式，Client中所有的链式调用都会报错。系统越庞大，这种修改的代价就越惊人，这正是很多遗留系统越来越难以维护的根源之一。
运用迪米特法则改进设计方案
改进的思路是：让类只暴露必要的公开方法，把内部的复杂结构封装起来。调用者需要什么信息，直接朋友就提供对应的方法，而不是把内部对象一层层递出去。重构后的代码如下：
public class Shop {
private Warehouse warehouse;
// 对外提供业务方法，隐藏内部结构
public String getSupplierContactInfo() {
return warehouse.getSupplierContactInfo();
}
}
public class Warehouse {
private Supplier supplier;
public String getSupplierContactInfo() {
return supplier.getContactInfo();
}
}
public class Supplier {
public String getContactInfo() {
return "联系人：张三，电话：13800000000";
}
}
// 客户端调用
public class Client {
public void doSomething() {
Shop shop = new Shop();
String info = shop.getSupplierContactInfo();
System.out.println(info);
}
}重构之后，Client只和Shop这一个直接朋友打交道，它完全不知道Warehouse和Supplier的存在。即使Shop内部的实现从持有仓库改成远程调用供应商服务，只要getSupplierContactInfo方法签名不变，Client的代码就一行都不用改。这就是最少知道原则带来的解耦收益。
当然，这种层层转发也会带来一个小问题：中间类可能出现一些纯粹为了转发而存在的委托方法，让代码量有所增加。这就需要在解耦和简洁之间做权衡。如果层次不深、调用频率不高，适量的委托方法是值得的；但如果转发链条过长，可能说明职责划分本身有问题，应该重新审视类的边界设计。
迪米特法则的注意事项与适用边界
任何设计原则都不是绝对的，迪米特法则也不例外，盲目套用反而会制造出大量冗余的包装类。在实践中需要注意以下几点。
第一，要区分依赖的合理性质。有些类天生就是数据载体，比如DTO、实体类，调用它们的getter方法获取属性是正常的，不能机械地认为所有点号链式调用都是错误的。判断的关键在于：调用链是否深入到了不该了解的领域逻辑。如果一行代码里出现连续多个点号，且跨越了不同的业务概念，就值得警惕。
第二，迪米特法则与单一职责原则、接口隔离原则往往配合使用。单一职责保证类只做一件事，接口隔离保证依赖最小化，迪米特法则保证通信对象最少化，三者共同服务于高内聚低耦合这一终极目标。在阅读开源框架源码时，你会发现优秀的框架往往在门面层做了大量封装，让使用者只需要面对极少数的入口类，这正是迪米特法则在架构层面的体现。
第三，一些现代Java框架的特性表面上看像是违反了迪米特法则，比如Stream流式操作中的一连串方法调用。实际上这不属于违反，因为链式调用的每个方法都返回同一个对象或其规范约定的类型，调用者与对象之间的了解程度并没有加深。真正违反法则的是那种深入陌生对象内部、跨越多层结构的调用，理解了这一点，就不会在实际编码中产生误判。
总的来说，迪米特法则的价值在于培养一种设计直觉：写代码时多问一句，我是否知道了不该知道的东西。保持类之间清爽的依赖关系，系统才能在需求变化时从容应对，这正是面向对象设计的精髓所在。