「设计模式」六大原则之六：最小知识原则小结

「设计模式」六大原则系列链接:
「设计模式」六大原则之一：单一职责小结
「设计模式」六大原则之二：开闭职责小结
「设计模式」六大原则之三：里氏替换原则小结
「设计模式」六大原则之四：接口隔离原则小结
「设计模式」六大原则之五：依赖倒置原则小结
「设计模式」六大原则之六：最小知识原则小结

六大原则体现很多编程的底层逻辑：高内聚、低耦合、面向对象编程、面向接口编程、面向抽象编程，最终实现可读、可复用、可维护性。

设计模式的六大原则有：

• Single Responsibility Principle：单一职责原则
• Open Closed Principle：开闭原则
• Liskov Substitution Principle：里氏替换原则
• Law of Demeter：迪米特法则（最少知道原则）
• Interface Segregation Principle：接口隔离原则
• Dependence Inversion Principle：依赖倒置原则
  把这六个原则的首字母联合起来（ L 算做一个）就是 SOLID （solid，稳定的），其代表的含义就是这六个原则结合使用的好处：建立稳定、灵活、健壮的设计。

本文介绍 SOLID 中的第六个原则：最小知识原则。

1. 最小知识原则（LOD）定义

最小知识则的英文翻译是：Law of Demeter，缩写是 LOD。英文翻译为：The Least Knowledge Principle。

产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。

又叫迪米特法则 不好记，我们最好记成最小知识则。

关于这个设计原则，我们先来看一下它最原汁原味的英文定义：

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.

翻译成中文：

每个模块（unit）只应该了解那些与它关系密切的模块（units: only units “closely” related to the current unit）的有限知识（knowledge）。或者说，每个模块只和自己的朋友“说话”（talk），不和陌生人“说话”（talk）。

再转化一下理解：

不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）。

2. 什么是“高内聚”呢

所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中，代码容易维护。

实际上，我们前面讲过的单一职责原则是实现代码高内聚非常有效的设计原则。

3. 什么是“松耦合”？

所谓松耦合是说，在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动。

实际上，依赖注入、接口隔离、基于接口而非实现编程，以及今天讲的迪米特法则，都是为了实现代码的松耦合。

4.应用举例

• 比如我们设计了用户管理类UserManager用来管理登录，登出等操作供调用端调用，但是具体的登录登出中的写入，清空用户缓存功能调用端是不了解的。

调用端 --> UserManager (用户管理类) --> UserCacheManager(用户缓存类)

• 再比如 租客、房东（房间）和中介的关系。可以包含代码模式的思想，租客只需要和中介通信，至于房东（房间）的信息，交给中介去管理就好了，比如可以把房间信息封装到中介类中，提供一个方法即可。

• 再比如明星、商业公司活动（或者粉丝见面会）和经济人的关系。

  总之：类 A 提供的 api 不满足 B 的需求，需要反复组合，这时候就需要一个中间类 C，用来协调 A 和 B 的关系，C 就是和事佬角色（中介角色）。

参考：

《设计模式之美》

《重学 Java 设计模式》

《Android 源码设计模式解析与实战》