迪米特法则要求类只与“直接朋友”交互：成员变量、方法参数、方法内创建对象及this本身；避免长链调用，应通过封装方法、门面或中介者解耦，兼顾可读性与封装性。

迪米特法则（Law of Demeter，LoD），也叫最少知识原则，核心就一句话：一个类只该和“直接朋友”打交道，不该越级去调用陌生对象的方法。

谁算你的“直接朋友”？

判断标准很具体：当前类的成员变量、方法参数、方法内部创建的对象、以及this本身——这些才是合法的“朋友”。比如你有个User类，它持有一个Profile对象作为字段，那Profile就是朋友；但Profile里嵌套的Address就不是，不能写user.getProfile().getAddress().getCity()这种长链调用。

怎么避免“陌生人”通信？

遇到需要跨层访问的情况，优先在“朋友”类里封装好所需能力：

• 在Profile类中加一个getCity()方法，让User直接调用user.getProfile().getCity()
• 用接口或门面（Facade）统一暴露有限能力，隐藏内部结构
• 引入中介者（Mediator）或服务类来转发请求，把多对多关系转为一对多

别为了LoD牺牲可读性

过度遵守可能带来大量“胶水方法”，让代码变臃肿。关键看实际影响：

• 如果Address实现经常变，而User又频繁依赖城市信息，那封装getCity()就值得
• 如果只是临时调试或脚本场景，短链调用一次问题不大
• 领域模型中天然紧密关联的对象（如订单与订单项），适度耦合反而更自然

访问权限要配合收紧

LoD不是光靠调用方式，还得靠封装支撑：

• 字段尽量设为private，不提供无意义的getter/setter
• 内部工具类或辅助对象不暴露给外部，避免被误当成“朋友”
• 构造函数参数精简，只接收真正需要协作的对象