如何利用迪米特法则实现“高内聚、低耦合”?(一)

发布于 2022-6-2 16:33
浏览
0收藏

 

     

   正文   
 

1 何为“高内聚、低耦合”?
“高内聚、低耦合”能有效地提高代码可读性、可维护性,缩小功能改动导致的代码改动范围。很多设计原则也都以实现代码“高内聚、低耦合”为目的,比如:

  • 单一职责原则
  • 面向接口,而非面向实现来编程
    “高内聚、低耦合”是个通用设计思想,可指导:
  • 不同粒度代码的设计与开发

如系统、模块、类,甚至函数

  • 不同开发场景
  • 如微服务、框架、组件、类库等
    本文主要围绕以“类”作为该设计思想的应用对象。
  • “高内聚”,指导类本身的设计
  • “低耦合”,指导类与类之间依赖关系的设计
    二者并非完全独立,高内聚有助于低耦合,低耦合又需要高内聚的支持。

1.1  高内聚

  • 相近的功能,应放到同一个类
  • 不相近的功能,不要放到同一个类
    相近的功能往往会被同时修改,放到同一类中,修改会比较集中,代码易维护。单一职责原则就是实现代码高内聚非常有效的设计原则。

1.2  低耦合
在代码中,类与类之间的依赖关系简单清晰。

即使两个类有依赖关系,一个类的代码改动不会或很少会导致依赖类的代码改动。依赖注入、接口隔离、面向接口编程及迪米特法则都是为实现低耦合。

1.3  “内聚”和“耦合”的关系
左边代码结构是“高内聚、低耦合”;右边“低内聚、紧耦合”:

如何利用迪米特法则实现“高内聚、低耦合”?(一)-开源基础软件社区

左边的代码设计:
类的粒度较小,每个类的职责都比较单一。相近功能都放到了一个类,不相近功能分割到多个类。这样类更加独立,代码内聚性更好。

因为职责单一,所以每个类被依赖的类就会比较少,代码低耦合。一个类的修改,只会影响到一个依赖类的代码改动。只需要测试这一个依赖类是否还能正常工作即可。

右边代码设计:
类粒度比较大,低内聚,功能大而全,不相近的功能放到了一个类中。导致很多其他类都依赖该类。修改这个类的某功能代码时,会影响依赖它的多个类。我们需要测试这三个依赖类,是否还能正常工作,“牵一发而动全身”。

2 迪米特法则
Law of Demeter,LOD,从名字看不出这是个啥。它还有另外一个名字:最小知识原则。

 

The Least Knowledge Principle: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.

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

 

结合实际,定义描述中的“模块”替换成“类”:

  • 不该有直接依赖关系的类之间,不要有依赖
  • 有依赖关系的类之间,尽量只依赖必要的接口(“有限知识”)
    所以,迪米特法则其实包含两部分,下面用两个案例分别解读。

 

3 案例
3.1 不该有直接依赖关系的类之间,不要有依赖
简化的搜索引擎爬取网页,包含如下主要类:

NetworkTransporter,负责底层网络通信,根据请求获取数据:

如何利用迪米特法则实现“高内聚、低耦合”?(一)-开源基础软件社区

HtmlDownloader,通过URL获取网页:

如何利用迪米特法则实现“高内聚、低耦合”?(一)-开源基础软件社区

Document,表示网页文档,后续的网页内容抽取、分词、索引都是以此为处理对象:

如何利用迪米特法则实现“高内聚、低耦合”?(一)-开源基础软件社区

 
如何重构?
这段代码虽然“能用”,但不够“好用”。

NetworkTransporter,作为一个底层网络通信类,应该尽可能通用,而不是只能下载HTML。所以,不应该直接依赖太具体的发送对象HtmlRequest,其设计违背迪米特法则,依赖了不该有直接依赖关系的HtmlRequest类。

假如你现在要去买东西,你肯定不会直接把钱包给收银员,让收银员自己从里面拿钱,而是你从钱包里把钱拿出来交给收银员。HtmlRequest对象相当于钱包,HtmlRequest里的address和content对象就相当于钱。

应将address和content交给NetworkTransporter,而非直接把HtmlRequest交给NetworkTransporter:

如何利用迪米特法则实现“高内聚、低耦合”?(一)-开源基础软件社区


Document的问题:

  • 构造器中的downloader.downloadHtml()逻辑复杂,耗时长,不应放到构造器,影响代码可测试性
  • HtmlDownloader对象在构造器通过new来创建,违反面向接口编程,也影响代码可测试性
  • 业务上说,Document网页文档没必要依赖HtmlDownloader类,违背迪米特法则
    问题虽多,但修改简单:

如何利用迪米特法则实现“高内聚、低耦合”?(一)-开源基础软件社区

文章转自公众号: JavaEdge

分类
标签
已于2022-6-2 16:33:23修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐