Java迪米特法则应用：减少对象接触降低系统脆弱性

在构建健壮的Java系统时，对象间的交互方式直接决定了代码的脆弱性。今天，我们就来聊聊一个能有效降低这种耦合度的设计原则——迪米特法则。它的核心思想很明确：限制对象间的直接接触，让每个对象只与它的“直接朋友”通信，从而将耦合控制在可控范围内。

简单来说，这个原则不是要消灭对象间的通信，而是要为这种通信建立清晰的边界和规则，避免不必要的依赖关系像藤蔓一样四处蔓延，最终让系统变得难以维护。

明确谁是你的“直接朋友”

那么，在Java的世界里，哪些对象才算是一个类的“合法朋友”呢？法则给出了明确的界定，只有以下四类：

• 自身创建的对象：例如在构造方法或内部方法中通过 new 关键字实例化的对象。
• 作为参数传入的对象：在方法签名中明确声明的参数。
• 自身的成员变量：通常是 private 字段，并且其类型是已知且受控的。
• 对象自身（this）：调用自己的方法或访问自己的字段。

违反这一界定的典型例子，就是那种长长的链式调用，比如 user.getProfile().getAddress().getCity()。对于 User 对象而言，Profile 是直接朋友，但 Address 和 City 就成了“陌生人”。这种写法将多层内部结构完全暴露出来。一旦底层如 Address 类需要重构、City 字段的访问权限改变或增加了校验逻辑，所有调用了这行代码的地方都可能需要修改，牵一发而动全身。

用委托方法代替层层点取

当需要获取深层信息时，正确的做法不是自己“穿透”层层对象去拿，而是让直接朋友“代劳”。这就是委托方法的用武之地。

• 我们可以在 Profile 类中增加一个 getCity() 方法，其内部实现去调用 address.getCity()。
• 这样，User 类就只需要调用 user.getProfile().getCity()，它完全不需要知道 Address 对象的存在。
• 未来，即使 Address 被拆分为 DomesticAddress 和 OverseasAddress，也只需在 Profile 的 getCity() 方法内部做好适配，User 的代码可以保持零修改。

这不仅仅是简单地添加一个Getter。其本质是封装语义：对调用者而言，它不再是“获取地址里的城市”，而是“获取用户所在城市”。后者是更稳定、更贴近业务的语言，受内部实现细节变化的影响更小。

返回值要克制，别交出内部容器或可变对象

方法返回值是对象对外暴露的另一个重要接口。如果直接返回内部可变对象的引用，无异于主动打开大门，邀请外部代码来修改内部状态，从而引入隐蔽的耦合。

• 反面例子：public List getItems() { return items; } —— 外部调用者拿到这个List后，可以进行 add 或 remove 操作，极易破坏对象内部状态的一致性。
• 改进方案一（防御性复制）：public List getItems() { return Collections.unmodifiableList(items); } 返回一个不可修改的视图。
• 改进方案二（提供最小能力接口）：更进一步，不返回整个容器，而是提供诸如 public int getItemCount()、public Item getItem(int index) 这样的方法。只给予外部所需的能力，而非整个数据结构的控制权。

同样的原则也适用于返回 Date、StringBuilder、原始数组等私有字段的引用。优先考虑返回它们的副本或不可变包装对象。

用协调者隔离多对象协作

在复杂的业务场景中，常常需要多个对象协作完成一项任务，例如“下单”：检查库存、扣减款项、创建订单、发送通知。如果让上层控制器（如Controller）直接按顺序调用所有这些服务，控制器就会与每一个服务产生紧密耦合。

• 高耦合的做法：Controller 直接调用 inventoryService.check() → paymentService.charge() → notifyService.send()。
• 符合迪米特法则的做法：引入一个协调者，例如 OrderService.place(Order order) 方法。由这个协调者内部来调度库存、支付、通知等各个组件。如此一来，InventoryService 不认识 PaymentService，PaymentService 也不依赖 NotifyService，它们只与协调者交互。
• 带来的好处：后续如果需要增加风控、积分、物流单等步骤，只需修改 OrderService 这个协调者内部的逻辑，而不会影响到其他已有的模块或上层的控制器。

这个协调者不一定总是一个全新的类，它也可以是某个现有服务中提供的聚合接口。关键在于，它将“谁该和谁说话”的复杂规则进行了收口和统一管理，简化了对象间的协作网络。