在构建高可维护的 Java 系统架构时，对象间的交互模式直接影响代码的健壮性与扩展性。本文将深入探讨一个关键的设计原则——迪米特法则（Law of Demeter），它通过限制对象间的直接接触，有效降低系统模块间的耦合度，从而提升整体架构的稳定性。
迪米特法则的核心并非禁止对象通信，而是为通信建立清晰的边界与规则，防止不必要的依赖关系无序扩散，最终导致系统难以迭代与维护。
界定“直接朋友”：明确合法通信对象
在 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—— 外部调用者获得此 List 后，可执行- getItems() { return items; }
add或remove操作，极易破坏对象内部状态的一致性。 - 改进方案一（防御性复制）：
public List返回一个不可修改的视图。- getItems() { return Collections.unmodifiableList(items); }
- 改进方案二（提供最小能力接口）：更进一步，不返回整个容器，而是提供如
public int getItemCount()、public Item getItem(int index)等方法。仅授予外部所需的最小能力，而非整个数据结构的控制权。
该原则同样适用于返回 Date、StringBuilder、原始数组等私有字段引用的场景。优先考虑返回其副本或不可变包装对象。
协调者模式：简化多对象协作网络
在复杂的业务逻辑中，常需多个对象协作完成一项任务，例如“创建订单”：涉及库存检查、支付扣款、订单生成、通知发送等步骤。若让上层控制器直接依次调用所有服务，控制器将与每个服务产生紧密耦合。
- 高耦合的实现：Controller 直接调用
inventoryService.check()→paymentService.charge()→notifyService.send()。 - 符合迪米特法则的优化：引入一个协调者，例如
OrderService.place(Order order)方法。由该协调者内部调度库存、支付、通知等组件。如此，InventoryService无需认识PaymentService，PaymentService也不依赖NotifyService，它们仅与协调者交互。 - 架构优势：后续若需增加风控、积分、物流等步骤，仅需修改
OrderService协调者内部的逻辑，不影响其他已有模块或上层控制器。
协调者不一定总是全新创建的类，也可以是某个现有服务中提供的聚合接口。关键在于将“对象间如何协作”的复杂规则进行收口与统一管理，从而简化整个系统的对象协作网络，提升 Java 系统架构的清晰度与可维护性。
