王争《设计模式之美》学习笔记
何为“高内聚、松耦合”?
- “高内聚、松耦合”是一个非常重要的设计思想,能够有效地提高代码的可读性和可维护性,缩小功能改动导致的代码改动范围。
- “高内聚”用来指导类本身的设计,“松耦合”用来指导类与类之间依赖关系的设计。
那到底什么是“高内聚”呢?
- 所谓高内聚,就是指相近的功能应该放到同一个类中,不相近的功能不要放到同一个类中。
- 相近的功能往往会被同时修改,放到同一个类中,修改会比较集中,代码容易维护。
我们再来看一下,什么是“松耦合”?
- 所谓松耦合是说,在代码中,类与类之间的依赖关系简单清晰。
- 即使两个类有依赖关系,一个类的代码改动不会或者很少导致依赖类的代码改动。
最后,我们来看一下,“内聚”和“耦合”之间的关系。
- 文中举例,通过两张图来对比。
- 左图中,类的粒度比较小,每个类的职责都比较单一。相近的功能都放到了一个类中,不相近的功能被分割到了多个类中。这样类更加独立,代码的内聚性更好。因为职责单一,所以每个类被依赖的类就会比较少,代码低耦合。一个类的修改,只会影响到一个依赖类的代码改动。我们只需要测试这一个依赖类是否还能正常工作就行了。
- 右图中,类粒度比较大,低内聚,功能大而全,不相近的功能放到了一个类中。这就导致很多其他类都依赖这个类。当我们修改这个类的某一个功能代码的时候,会影响依赖它的多个类。我们需要测试这三个依赖类,是否还能正常工作。这也就是所谓的“牵一发而动全身”。
- 另外,高内聚、低耦合的代码结构更加简单、清晰,相应地,在可维护性和可读性上确实要好很多。
“迪米特法则”理论描述
- 迪米特法则的英文翻译是:Law of Demeter,缩写是LOD。
- 还有另外一个更加达意的名字,叫作最小知识原则,英文翻译为:The Least Knowledge Principle。
- 每个模块(unit)只应该了解那些与它关系密切的模块(units: only units “closely” related to the current unit)的有限知识(knowledge)。或者说,每个模块只和自己的朋友“说话”(talk),不和陌生人“说话”(talk)。
- 不该有直接依赖关系的类之间,不要有依赖;有依赖关系的类之间,尽量只依赖必要的接口(也就是定义中的“有限知识”)。
不该有直接依赖关系的类之间,不要有依赖
文中举例
- 简化版的搜索引擎爬取网页的功能,包含三个类。
- NetworkTransporter 类负责底层网络通信,根据请求获取数据,有方法 send(HtmlRequest htmlRequest)
- HtmlDownloader 类用来通过 URL 获取网页,有方法downloadHtml(),其中调用NetworkTransporter.send()
- Document 类表示网页文档,后续的网页内容抽取、分词、索引都是以此为处理对象,构造方法中调用HtmlDownloader.downloadHtml()
问题分析
- NetworkTransporter 类:
- 作为一个底层网络通信类,不只是服务于下载 HTML,所以,我们不应该直接依赖太具体的发送对象 HtmlRequest。
- 违背迪米特法则,依赖了不该有直接依赖关系的 HtmlRequst 类。
- 去商店买东西不能直接把钱包给收银员,而是把钱从钱包里拿出来给收银员,应该把 HtmlRequst 里的 address 和 content 交给 NetworkTransporter。
- HtmlDownloader 类:
- 设计没有问题,只需要对应修改调用NetworkTransporter.send() 的参数。
- Document 类:
- 构造方法中逻辑过于复杂,耗时长,增加测试复杂度。
- 构造方法中 new 了类 HtmlDownloader,违反了基于接口而非实现编程。
- Document 网页文档没必要依赖 HtmlDownloader 类,违背了迪米特法则。
- 增加一个工厂类 DocumentFactory 来创建 Document,构造方法中传入 HtmlDownloader,在方法 createDocument() 中new Document()。
有依赖关系的类之间,尽量只依赖必要的接口
文中举例
- Serialization 类负责对象的序列化和反序列化。
- Serialization 类中有方法 serialize() 和 deserialize()。
- 单看这个类没问题,但是放在一定的应用场景中,我们的项目中有些类只用到序列化,有些类只用到反序列化。违背迪米特法则后半部分“有依赖关系的类之间,尽量只依赖必要的接口“。
迪米特法优化
- 拆分成两个类,一个只负责序列化(Serializer 类),一个只负责反序列化(Deserializer 类)。
- 但是此方案违背高内聚的设计思想,相近的功能要放到同一个类中,这样可以方便功能修改的时候,修改的地方不至于过于分散。
接口隔离优化
- 引入两个接口,Serializable 和 Deserializable。
- 类 Serialization 实现以上两个接口中的序列化和反序列化方法。
- 在调用时,虽然传入包含序列化和反序列化的 Serialization 实现类,但是需要用到序列化就依赖 Serializable 接口,需要用到反序列化就依赖 Deserializable。
- 基于最小接口而非最大实现编程。
辩证思考与灵活应用
- 以上例子中,整个类只包含序列化和反序列化两个操作,只用到序列化操作的使用者,即便能够感知到仅有的一个反序列化函数,问题也不大。是否过度设计呢?
- 只包含两个操作,确实没有太大必要拆分成两个接口,如果添加更多序列化和反序列化的方法,那么拆分就很有必要。
- 序列化的使用者,没有必要了解反序列化的”知识“,按照迪米特法则,将反序列化和序列化的功能隔离开来,减少耦合和测试工作量。