一个订单服务里，一行代码安静地躺着：`order.getCustomer().getAddress().getCity()`。它不报错、不打日志，甚至单测也能过。可当用户中心、地址库、订单表任意一方调整结构，这行代码就像一根被抽掉线头的毛衣，整个订单、支付、物流模块开始连锁报空指针。我是老李，在 Java 服务端摸爬滚打多年，见过太多因为对象之间‘太熟’而崩掉的系统。为什么现在要讲迪米特法则？因为系统越拆越细，单体内部对象之间的越界访问反而更隐蔽；开发节奏越快，越需要几条朴素原则守住边界。

## 01、痛点

```
订单服务
   |
   v
order.getCustomer().getAddress().getCity()
   |         |              |
   v         v              v
Customer  Address        City 字符串
   ^         ^              ^
   |_________|______________|
       一路“串门”，谁都能看内部
```

很多项目都有类似代码。表面看，一行代码就拿到了城市，简洁、高效。但背后是 OrderService 直接深入了 Customer 和 Address 的内部。对订单来说，它只需要知道‘收货城市’这一个结论，却被迫知道了‘客户下面有地址，地址下面有城市’两级结构。

一旦产品要求支持默认地址、多个收货地址，或者地址改为经纬度加区域编码，所有写 `getCustomer().getAddress().getCity()` 的地方都要改。更糟的是，这些地方分散在订单、支付、物流、风控等不同模块，形成典型的牵一发动全身。

这类链式调用还有一个名字叫‘火车残骸’。它常常伴随大量判空：`if (order.getCustomer() != null && order.getCustomer().getAddress() != null && order.getCustomer().getAddress().getCity() != null) { ... }`。业务逻辑被淹没在防御性判断里。

测试也很痛苦。为了测一个订单方法，可能要 mock Customer、Address、CityService 等一串对象。测试代码比业务代码还长，而且脆弱，内部结构一变，所有 mock 都要重写。

更隐蔽的越界不止链式调用：方法参数传入一个对象，却在方法内部访问该对象的内部对象；返回一个集合，外部拿到集合后再深入取内部字段；跨模块直接使用另一个服务的内部 DTO。这些都会让系统快速腐化。

## 02、是什么

```
对象 A ──直接朋友──> 对象 B
   \                /
    \              /
     X  不要和陌生人说话  X
      \            /
       \          /
        对象 C（朋友的朋友）
```

迪米特法则（Law of Demeter, LoD），又称最少知识原则（Principle of Least Knowledge）。它的核心表述是：一个对象应当对其他对象有尽可能少的了解，只和直接朋友通信。

该法则于 1987 年由美国东北大学的 Ian Holland 在 Demeter 项目中提出。Demeter 是希腊神话中的农业女神，寓意‘各管各的一亩三分地’。放到代码里，就是别去打听朋友的朋友。

直接朋友通常包括：当前对象自身的成员变量；方法参数传入的对象；方法内部创建的对象；当前对象方法直接返回的对象。也就是说，你可以调用自身、参数、成员变量、以及自己 new 出来的对象的方法，但不应该越过它们去调用它们的朋友的方法。

Java 中最典型的违反信号就是 `a.getB().getC().getD()`。注意，流式 API 如 `list.stream().filter(...).map(...)` 并不违反迪米特，因为你始终在和同一个流对象说话，没有跨越多个对象的内部边界。判断标准不是看有没有点号，而是看是不是打听了陌生人。

迪米特法则不是‘不准用 getter’，而是‘不要用 getter 去挖别人内部结构’。如果 Customer 暴露 getAddress，并不是罪过；但 OrderService 拿到 getAddress 后又拿 getCity，就是越过 Customer 去认识 Address 的内部了。

## 03、为什么

```
高耦合：A → B → C → D
        一条链上的蚂蚱

低耦合：A → B
        B → C
        C → D
        边界清晰，各自独立
```

为什么值得遵守迪米特法则？因为‘知道得多’意味着‘耦合得深’。对象之间的依赖本质上是知识的传递。A 知道 B 有 getAddress，B 将来改掉 getAddress，A 就必须跟着改。

遵守迪米特能让封装更完整。封装讲的是隐藏内部实现，迪米特讲的是调用方不要主动去挖内部实现。一个类把自己的结构藏好，调用方只依赖稳定的业务方法，改起来自然安全。

从可维护性看，最少知识让变更影响面变小。一个内部字段的调整，不再需要全项目搜索变更。从可测试性看，测试只需要和直接朋友打交道，不需要为无关的内部对象造桩。

当然，迪米特也有代价。为了满足最少知识，可能要在对象上增加一些转发方法或门面，比如 Customer 增加 getCity() 或 Order 增加 getCustomerCity()。如果过度使用，类会膨胀，方法变多。对于纯数据对象、DTO、值对象，也许链式访问是务实的选择。所以这是一个权衡，而不是教条。

现代 Java 设计里，record、Optional、Stream 等机制能让数据流更干净，但它们本身不会自动解决跨边界访问。关键是边界意识：每个对象只暴露自己负责的知识。

## 04、架构

```
表现层(Controller)
      ↓ 只调用
应用层(Service)
      ↓ 只调用
领域层(Domain)
      ↓ 只调用
基础设施层(Infrastructure)
      ↓
数据库/消息/外部服务
```

迪米特法则在架构层面同样适用。分层架构中，每一层只应该和直接下层接触。Controller 不应该绕过 Service 直接访问 Repository，更不应该知道数据库表结构。否则服务边界形同虚设。

在微服务体系中，如果调用方需要用户服务、库存服务、价格服务的数据，不应该自己连续调用三个服务并手动拼装；可以引入 API 网关或 BFF 做聚合，调用方只依赖一个聚合接口。这样下游服务内部变化，不会传导给所有上游调用者。

在领域驱动设计里，聚合根就是迪米特的体现。外部只能通过聚合根修改内部实体，比如 Order 提供 addItem()，而不是暴露 List<OrderItem> 让外部随意 add。前者让订单聚合的规则可控，后者让外部了解订单内部结构。

在 Java 模块化层面，通过 public 接口和包私有实现限制外部知识。一个模块只导出少数接口，内部实现类全部隐藏。Java 9 的模块系统甚至可以声明哪些包对外导出，这就是从语言层面限制知识范围。

架构上，迪米特与接口隔离、依赖倒置常常一起出现。接口越小，调用方了解得越少；依赖抽象，则不关心具体实现。三者共同塑造高内聚低耦合的系统。

## 05、实战

```
反例：
order.getCustomer().getAddress().getCity()
       ↑ 调用者需知道 Customer、Address、City 三级

正例：
order.getCustomerCity()
       ↑ 调用者只向 Order 开口
```

下面用 Java 代码演示几个典型场景。场景一：电商订单中心判断订单是否属于偏远地区。

反例：
```java
public class OrderService {
    public boolean isRemoteOrder(Order order) {
        String city = order.getCustomer().getAddress().getCity();
        return RemoteCityRegistry.contains(city);
    }
}
```

这段代码里，OrderService 为了拿城市，跨过了 Customer 和 Address 两个边界。改进方式是在 Order 上增加方法：

```java
public class Order {
    private Customer customer;
    public String getCustomerCity() {
        return customer.getCity();
    }
}
```

此时调用方简化为：
```java
public boolean isRemoteOrder(Order order) {
    String city = order.getCustomerCity();
    return RemoteCityRegistry.contains(city);
}
```

OrderService 不再关心 Customer 内部有没有 Address，只跟 Order 说话。

更进一步，如果偏远地区判断属于客户域的业务，可以放到 Customer 里：
```java
public class Customer {
    private Address address;
    public boolean isInRemoteArea() {
        return RemoteCityRegistry.contains(address.getCity());
    }
}
```

这样 OrderService 甚至不关心城市字符串。

场景二：员工部门与经理。反例：
```java
String phone = employee.getDepartment().getManager().getPhone();
```

调用者需要知道部门内部有经理，经理有电话。改进：
```java
public class Employee {
    private Department department;
    public String getManagerPhone() {
        return department.getManager().getPhone();
    }
}
```

外部只调用 `employee.getManagerPhone()`。

场景三：方法参数内部对象。反例：
```java
public class ReportGenerator {
    public void print(Employee emp) {
        String managerName = emp.getDepartment().getManager().getName();
        System.out.println(managerName);
    }
}
```

方法参数 emp 本该是直接朋友，但方法内部又去访问 emp 的朋友 Department，再访问 Department 的朋友 Manager。改进为在 Employee 上提供 getManagerName()。

场景四：集合内部元素再深入。反例：
```java
for (OrderItem item : order.getItems()) {
    if (item.getProduct().getCategory() == ProductCategory.BOOK) { ... }
}
```

这里调用者知道 OrderItem 有 Product，Product 有 Category。改进可以让 OrderItem 提供 isBook()：
```java
for (OrderItem item : order.getItems()) {
    if (item.isBook()) { ... }
}
```

判断书籍的逻辑被封装在 OrderItem 内部，外部只关心结论。

在实际重构中，可以先找出 getter 链，再判断该知识应该归属哪个对象。不要只是机械地添加转发方法，否则可能出现‘中间人’坏味道。如果某个对象只是数据容器，链式读取可以酌情保留；一旦涉及业务规则，就应该收口。

## 06、洞见

```
知识 → 依赖 → 耦合 → 修改成本
   ↑
  少知道，少依赖，少痛苦
```

迪米特法则背后是一个朴素的等式：知识约等于依赖。你了解对方内部越多，对方改变时你的痛苦就越大。这不是玄学，而是软件工程里反复出现的因果。

它和封装互为表里：封装负责关上门，迪米特负责管住手。封装说‘不要让我看到’，迪米特说‘我不应该去看’。两者结合，对象才能成为真正自治的单元。

接口隔离也与之呼应。如果接口很小，调用者知道得就少；如果接口很大，调用者很容易依赖一堆无关方法。依赖倒置则从抽象层面进一步降低知识，因为抽象本身减少了实现细节。

但迪米特不能走向极端。为了‘最少知识’而在类里塞满转发方法，会制造新的坏味道。例如 Customer 有几十个方法和 Address 一一对应，Customer 就成了冗余的中间人。正确做法是让行为归属到正确的对象：城市查询属于 Customer 的业务能力，而不是简单转发。

测试是迪米特的试金石。当你发现为了一个简单逻辑要 mock 一堆对象时，未必是测试工具不好用，很可能是知识泄露了。好的设计会让测试对象只有一个直接朋友。

在架构上，所有边界——包边界、模块边界、服务边界、聚合边界——本质上都在限制知识。边界越清晰，内部变化越不会外溢。所谓高内聚低耦合，就是让大家只和直接朋友说话。

## 07、行动

```
查：扫描 get 链长度 > 2
删：移除不必要的 getter
包：给边界对象加行为方法
测：用单测验证边界收口
```

行动的第一步是排查。在项目里搜索 `get` 连续调用的模式，比如用静态扫描工具或人工 code review 标记所有超过两次的链式调用。重点检查订单、用户、库存等核心业务模块。

第二步是判断归属。对每个链式调用，问一句：这段知识应该由哪个对象负责？如果是城市，应该由 Customer 或 Order 提供方法；如果是经理电话，应该由 Employee 提供。把行为放到正确对象上，而不是在调用方拼装。

第三步是抽象门面。对于跨模块依赖或第三方库，可以引入门面类型，隐藏内部细节。比如文件处理模块，对外只暴露 FileService 的几个方法，而不要暴露底层 client、连接池、解析器。

第四步是编写测试。修改后，重新写单元测试。理想情况下，测试只需要 mock 一个直接朋友。如果测试代码依然需要构造多层对象，说明边界还没有收口。

第五步是团队约定。将‘getter 链不超过 2 层’纳入评审标准，同时对 DTO、值对象等纯数据对象列出例外。约定要务实，不要机械执行。

提供一个小清单供评审时使用：
- 方法内是否访问了参数对象的内部对象？
- 是否通过成员变量再访问另一个对象的成员？
- 是否将内部集合直接返回给外部？
- 是否为测试 mock 了过多无关对象？

重构要小步走，先覆盖测试，再改代码。原则是用来减少痛苦，不是增加痛苦。

## 08、小结

少知道一点，就少一点崩溃。

迪米特法则不是冰冷的教条，而是一种边界意识。每一个 `get` 链，本质上都是一次对象之间的越界握手。收住手，边界才会清晰，系统才扛得住变化。以后再看到 `a.getB().getC().getD()`，可以停下来问一句：它凭什么都认识？

## 09、链接与概念说明

概念澄清：
- 迪米特法则与封装：封装关注类自身隐藏实现细节；迪米特关注调用方不应依赖其他对象的内部实现。两者一个对内，一个对外。
- 迪米特法则与接口隔离：接口隔离原则要求接口尽量小且专用；迪米特要求调用方只依赖直接接口，避免跨对象访问。小接口天然支持最少知识。
- 迪米特法则与依赖倒置：依赖倒置强调依赖抽象而非具体实现；迪米特强调依赖范围尽量小。抽象程度高且接口精简的设计，通常也符合迪米特。

延伸阅读：
- Ian Holland 关于 Demeter 项目的原始资料；
- 《程序员修炼之道》中关于正交性与羞于暴露的章节；
- 《实现领域驱动设计》中关于聚合边界的讨论；
- 重构领域对火车残骸与中间人两种坏味道的论述。

本文所有示例均为 Java 通用设计，不依赖任何具体框架或产品。

一个订单服务里，一行代码安静地躺着：order.getCustomer().getAddress().getCity()。它不报错、不打日志，甚至单测也能过。可当用户中心、地址库、订单表任意一方调整结构，这行代码就像一根被抽掉线头的毛衣，整个订单、支付、物流模块开始连锁报空指针。我是老李，在 Java 服务端摸爬滚打多年，见过太多因为对象之间‘太熟’而崩掉的系统。为什么现在要讲迪米特法则？因为系统越拆越细，单体内部对象之间的越界访问反而更隐蔽；开发节奏越快，越需要几条朴素原则守住边界。

别再让对象互相“串门”了：迪米特法则在 Java 设计中的破局之道

从一条 getter 链式调用讲起，拆解迪米特法则的定义、原理、架构落地与 Java 编码改造，帮你降低耦合，写出更易维护的代码。

架构师

编程语言

架构设计

后端

订单服务中链式调用getCustomer().getAddress().getCity()暗藏高风险，违反迪米特法则，导致跨模块耦合、判空繁琐、测试脆弱。通过收口行为到边界对象、精简getter链、建立团队约定，可提升系统抗变更能力，让每一层只和直接朋友通信，降低知识依赖，避免连锁崩溃。

软件工程

单元测试

文件处理

代码解释

数据库

数据流

容器

Java

2026上云采购 | AI焕新·智启新局

cngw

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

别再让对象互相“串门”了：迪米特法则在 Java 设计中的破局之道-腾讯云开发者社区-腾讯云

别再让对象互相“串门”了：迪米特法则在 Java 设计中的破局之道

别再让对象互相“串门”了：迪米特法则在 Java 设计中的破局之道

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐