【设计模式之美】重构(三)之解耦方法论:如何通过封装、抽象、模块化、中间层等解耦代码?

这篇具有很好参考价值的文章主要介绍了【设计模式之美】重构(三)之解耦方法论:如何通过封装、抽象、模块化、中间层等解耦代码?。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一. “解耦”概述

重构可以分为大规模高层重构(简称“大型重构”)和小规模低层次重构(简称“小型重构”)。
通过解耦对代码重构,就是保证代码不至于复杂到无法控制的有效手段。

 

代码是否需要“解耦”?

  1. 看修改代码会不会牵一发而动全身。
  2. 依赖关系是否复杂
    把模块与模块之间、类与类之间的依赖关系画出来,根据依赖关系图的复杂性来判断是否需要解耦重构。

 

二. 如何给代码“解耦”?

1. 封装与抽象

封装和抽象作为两个非常通用的设计思想,可以应用在很多设计场景中,比如系统、模块、lib、组件、接口、类等等的设计。封装和抽象可以有效地隐藏实现的复杂性,隔离实现的易变性,给依赖的模块提供稳定且易用的抽象接口。

比如,Unix 系统提供的 open() 文件操作函数,我们用起来非常简单,但是底层实现却非常复杂,涉及权限控制、并发控制、物理存储等等。

  1. 我们通过将其封装成一个抽象的 open() 函数,能够有效控制代码复杂性的蔓延,将复杂性封装在局部代码中。
  2. 因为 open() 函数基于抽象而非具体的实现来定义,所以我们在改动 open() 函数的底层实现的时候,并不需要改动依赖它的上层代码,也符合我们前面提到的“高内聚、松耦合”代码的评判标准。

 

2. 中间层

2.1. 引入中间层能简化模块或类之间的依赖关系

下面这张图是引入中间层前后的依赖关系对比图。在引入数据存储中间层之前,A、B、C 三个模块都要依赖内存一级缓存、Redis 二级缓存、DB 持久化存储三个模块。在引入中间层之后,三个模块只需要依赖数据存储一个模块即可。

从图上可以看出,中间层的引入明显地简化了依赖关系,让代码结构更加清晰。

【设计模式之美】重构(三)之解耦方法论:如何通过封装、抽象、模块化、中间层等解耦代码?,设计模式,设计模式,重构

2.2. 引入中间层可以起到过渡的作用,能够让开发和重构同步进行,不互相干扰。

比如,某个接口设计得有问题,我们需要修改它的定义,同时,所有调用这个接口的代码都要做相应的改动。如果新开发的代码也用到这个接口,那开发就跟重构冲突了。为了让重构能小步快跑,我们可以分下面四个阶段来完成接口的修改

  1. 引入一个中间层,包裹老的接口,提供新的接口定义。
  2. 新开发的代码依赖中间层提供的新接口。
  3. 将依赖老接口的代码改为调用新接口。
  4. 确保所有的代码都调用新接口之后,删除掉老的接口。

这样,每个阶段的开发工作量都不会很大,都可以在很短的时间内完成。重构跟开发冲突的概率也变小了。

 

3. 模块化

合理地划分模块能有效地解耦代码,提高代码的可读性和可维护性。所以,我们在开发代码的时候,一定要有模块化意识,将每个模块都当作一个独立的 lib 一样来开发,只提供封装了内部实现细节的接口给其他模块使用,这样可以减少不同模块之间的耦合度。

实际上,从刚刚的讲解中我们也可以发现,模块化的思想无处不在,像 SOA、微服务、lib 库、系统内模块划分,甚至是类、函数的设计,都体现了模块化思想。

如果追本溯源,模块化思想更加本质的东西就是分而治之。

 

4. 其他设计思想和原则

4.1. 单一职责原则

高内聚会让代码更加松耦合,而实现高内聚的重要指导原则就是单一职责原则。模块或者类的职责设计得单一,而不是大而全,那依赖它的类和它依赖的类就会比较少,代码耦合也就相应的降低了。

 

4.2. 基于接口而非实现编程

基于接口而非实现编程能通过接口这样一个中间层,隔离变化和具体的实现。这样做的好处是,在有依赖关系的两个模块或类之间,一个模块或者类的改动,不会影响到另一个模块或类。

实际上,这就相当于将一种强依赖关系(强耦合)解耦为了弱依赖关系(弱耦合)。

 

4.3. 依赖注入

跟基于接口而非实现编程思想类似,依赖注入也是将代码之间的强耦合变为弱耦合。尽管依赖注入无法将本应该有依赖关系的两个类,解耦为没有依赖关系,但可以让耦合关系没那么紧密,容易做到插拔替换。

 

4.4. 多用组合少用继承

  • 继承是一种强依赖关系,父类与子类高度耦合,且这种耦合关系非常脆弱,牵一发而动全身,父类的每一次改动都会影响所有的子类。
  • 组合关系是一种弱依赖关系,这种关系更加灵活,所以,对于继承结构比较复杂的代码,利用组合来替换继承,也是一种解耦的有效手段。

 

4.5. 迪米特法则

迪米特法则讲的是,不该有直接依赖关系的类之间,不要有依赖;有依赖关系的类之间,尽量只依赖必要的接口。从定义上,我们明显可以看出,这条原则的目的就是为了实现代码的松耦合。

 
 
《设计模式之美》-- 王争文章来源地址https://www.toymoban.com/news/detail-793652.html

到了这里,关于【设计模式之美】重构(三)之解耦方法论:如何通过封装、抽象、模块化、中间层等解耦代码?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Java设计模式 规范与重构】 二 重构的保障:单元测试,以及如何提高代码可测试性

    其实之前的工作中强调过很多次自己做测试的重要性,例如讲单元测试的: 【C#编程最佳实践 一】单元测试实践 ,讲单元测试规范的 【阿里巴巴Java编程规范学习 四】Java质量安全规约 ,讲接口测试的: 【C#编程最佳实践 十三】接口测试实践 ,这里旧事重提就不再详细展开

    2023年04月25日
    浏览(49)
  • 【设计模式】深入理解中介者模式,解耦对象之间的复杂交互,实现用户之间的消息传递,优化飞机之间的航线协调,构建高效的系统交互方式

    中介者模式是一种行为型设计模式,其核心思想是通过引入一个中介者对象来封装一组对象之间的交互。这种模式可以降低对象之间的耦合度,使得对象之间的交互更加灵活和可维护。 在现实世界中,我们经常会遇到需要协调多个对象之间交互的场景,例如聊天室中的用户之

    2024年01月23日
    浏览(35)
  • 设计模式第九讲:常见重构技巧 - 去除不必要的!=

    项目中会存在大量判空代码,多么丑陋繁冗!如何避免这种情况?我们是否滥用了判空呢?本文是设计模式第九讲,讲解常见重构技巧:去除不必要的!= 通常是这样的 初步的,使用Apache Commons,Guvava,Hutool等 StringUtils 考虑用Assert断言 逐级判断空,还是抛出自定义异常,还是

    2024年02月11日
    浏览(35)
  • 《微服务架构设计模式》第十三章 微服务架构的重构策略

    1、为什么重构 单体地狱造成的业务问题: 交付缓慢 充满故障的软件交付 可扩展性差 2、重构形式 1、一步到位 你企图从零开始开发一个全新的基于微服务的应用程序(彻底替换遗留的单体应用)。虽然从头开始并抛弃老代码库听起来很有吸引力,但它的风险极高,很可能以

    2024年02月16日
    浏览(36)
  • 设计模式第八讲:常见重构技巧 - 去除多余的if else

    最为常见的是代码中使用很多的if/else,或者switch/case;如何重构呢?方法特别多,本文是设计模式第八讲,带你学习其中的技巧。 通常业务代码会包含这样的逻辑:每种条件下会有不同的处理逻辑。比如两个数a和b之间可以通过不同的操作符(+,-,*,/)进行计算,初学者通

    2024年02月10日
    浏览(33)
  • Java设计模式 (一) 模板方法设计模式

    什么是模板方法设计模式? 模板方法设计模式是一种行为型设计模式,它定义了一个算法的骨架,并将一些步骤的具体实现延迟到子类中。模板方法模式可以帮助确保在算法的不同部分中保持一致性,同时也允许子类根据需要进行具体实现。 模板方法模式的关键特点包括:

    2024年02月12日
    浏览(36)
  • 设计模式---模板方法模式

            所谓模板方法模式,就是提供一种方法的模板来实现一种规范,其他人可以利用这个模板定义自己的逻辑。         在Java编程中的应用,主要就是通过接口或者抽象类来实现的,抽象类中可以把逻辑函数声明为final类型,表示不能被重写,即不能改变逻辑。在接口中

    2024年04月24日
    浏览(37)
  • 设计模式——模板方法模式

    模板方法模式(Template Method Pattern)是一种行为型设计模式,它在抽象类中定义了一个算法的框架,并将一些步骤延迟到子类中实现。这种模式使得子类可以在不改变算法结构的情况下重写算法中的某些特定步骤。 抽象模板类(Abstract Template Class): 定义一个操作中的算法骨架

    2024年01月17日
    浏览(38)
  • 设计模式-工厂方法模式

         工厂方法模式(Factory Method Pattern)是一种常用的类创建型设计模式,它属于对象的创建型模式,主要用来封装对象的创建过程。在该模式中,一个抽象工厂定义了一个接口用于创建产品对象,但实际的实例化延迟到子类中进行,也就是说,具体的产品是由其对应的工厂

    2024年01月17日
    浏览(39)
  • 设计模式—模板方法模式

    定义一个操作的流程框架,而将流程中一些步骤延迟到子类中实现。使得子类在不改变流程结构的情况下,重新定义流程中的特定步骤。 主要角色: 抽象类: 负责给出操作流程的轮廓或框架,由模板方法和若干基本方法组成。   1、抽象方法:由抽象类声明,在具体子类中实

    2024年02月10日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包