迪米特法则¶
约 557 个字 15 行代码 1 张图片 预计阅读时间 3 分钟
场景：第一天上班装电脑¶
小菜第一天上班领电脑：人事小杨介绍 IT 部小张；小张外出，小李推诿；无人协调，小菜空等一上午。大鸟指出：若存在 IT 主管统一分配任务，或只需找「IT 部」而不必认识具体同事，问题就解决了——这正是 迪米特法则 的职场版。
原则定义¶
迪米特法则（Law of Demeter，LoD），又称 最少知识原则：
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
前提¶
- 每个类 尽量降低 成员的访问权限（
private封装）。 - 根本思想：强调类之间的松耦合——耦合越弱，越有利于复用；修改一个类时，波及相关类越少越好。
与依赖倒转的关系¶
- IT 部 → 抽象类或接口
- 小张、小李 → 具体类
- 客户端只依赖 IT 部 接口，由主管（或部门入口） 转发 调用——既满足 面向接口编程（DIP），也满足 最少知识（LoD）。
打电话时应说「IT 部，电脑坏了」，而不是「小张在吗？小李在吗？」——减少对具体类的直接依赖。
简单对比¶
Java
// 违反 LoD：客户端直接操作多个子系统细节
class Client {
void goHome() {
new SubSystemA().operationA();
new SubSystemB().operationB();
new SubSystemC().operationC();
}
}
// 更符合 LoD：只与 Facade（第三者）交互
class Client {
void goHome() {
new Facade().operation();
}
}
这与 外观模式 紧密相关：Facade 作为 第三者，封装子系统，客户端 只知道 Facade。
小结¶
| 要点 | 说明 |
|---|---|
| 别名 | 最少知识原则 |
| 目标 | 降低类间直接耦合 |
| 实践 | 只与直接朋友通信；复杂协作通过中介/Facade |
| 收益 | 信息隐藏促进复用；内部人员变动不影响客户端 |
「无熟人难办事」的反面，是 好的架构让你不必认识所有人——只要认识对的 入口 就够了。