迪米特法则如何减少对象通信？

迪米特法则（最少知识原则）并非追求绝对的零耦合，而是通过“只与朋友通信”这一简洁准则，有效遏制对象间过度依赖和深层嵌套调用——它教你用委托方法替代冗长的火车式链式访问、以抽象/不可变接口封装内部结构、并借助协调者统一调度多对象协作，从而在不牺牲功能的前提下显著提升代码的可维护性、可测试性与演化韧性；掌握它，就是掌握了让系统复杂度不再随业务增长而失控的关键设计智慧。

迪米特法则（Law of Demeter，LoD），又称“最少知识原则”，核心思想是：一个对象应当对其他对象有尽可能少的了解，只与“朋友”通信，不与“陌生人”直接交互。它不是要消灭所有耦合，而是通过限制调用链长度、隐藏内部结构，降低模块间依赖，提升可维护性和可测试性。

只调用“自己创建的”或“作为参数传入的”对象

这是LoD最直接的落地规则。对象只能调用自身属性、方法返回的对象（前提是该方法属于“朋友”类）、方法参数中的对象，以及自己创建的新对象。

• ✅ 允许：order.getCustomer().getName() —— 如果getCustomer()是Order的直接方法，且Customer是Order的“朋友”（如被封装为私有字段或由构造器注入）
• ❌ 禁止：order.getShippingAddress().getCity().toUpperCase() —— 这是典型的“火车式调用”，暴露了Order → ShippingAddress → City三层内部结构，违反LoD
• ✅ 替代做法：在Order中提供高阶方法，如order.getShippingCity()，把细节封装起来

用委托代替深层导航

当需要获取嵌套对象的某个属性或执行某操作时，不要层层点取，而应在当前类中定义委托方法，把请求转给合适的协作对象。

• 例如，用户想查订单的收货人手机号：
  ❌ user.getOrder().getDelivery().getReceiver().getPhone()
  ✅ 在User中加方法：getUserPhoneForLatestOrder()，内部协调Order和Delivery，对外只暴露语义清晰的接口
• 好处是：一旦Delivery结构变更（比如拆分成Express和SelfPickup），只需修改委托方法，调用方完全无感

避免在方法中暴露内部组成对象

返回值类型应尽量抽象，不泄露实现细节。尤其警惕返回私有字段的引用（尤其是可变对象），这等于主动打破封装。

• ❌ 不推荐：public List getItems() { return items; } —— 外部可直接修改内部列表
• ✅ 更安全：public List getItems() { return new ArrayList(items); } 或返回Collections.unmodifiableList(items)
• ✅ 更彻底：public int getItemCount()、public Item getItemAt(int i) —— 只暴露必要能力，不交出容器本身

用中介或外观模式解耦复杂协作

当多个对象天然需要协同完成某任务（如下单流程涉及库存、支付、通知），不要让客户端直接串联它们，而是引入一个协调者（如OrderService）统一调度。

• 客户端只需调用orderService.place(order)，无需知道库存是否充足、支付是否成功、短信是否发送
• 协调者内部按需调用各组件，但各组件之间不直接通信（如InventoryService不调PaymentService）
• 这种分层使单元测试更简单——可单独Mock协调者依赖的每个服务

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~