30 | 理论四：如何通过封装、抽象、模块化、中间层等解耦代码？

王争



该思维导图由 AI 生成，仅供参考

前面我们讲到，重构可以分为大规模高层重构（简称“大型重构”）和小规模低层次重构（简称“小型重构”）。大型重构是对系统、模块、代码结构、类之间关系等顶层代码设计进行的重构。对于大型重构来说，今天我们重点讲解最有效的一个手段，那就是“解耦”。解耦的目的是实现代码高内聚、松耦合。关于解耦，我准备分下面三个部分来给你讲解。
“解耦”为何如此重要？
如何判定代码是否需要“解耦”？
如何给代码“解耦”？
话不多说，现在就让我们正式开始今天的学习吧！
“解耦”为何如此重要？软件设计与开发最重要的工作之一就是应对复杂性。人处理复杂性的能力是有限的。过于复杂的代码往往在可读性、可维护性上都不友好。那如何来控制代码的复杂性呢？手段有很多，我个人认为，最关键的就是解耦，保证代码松耦合、高内聚。如果说重构是保证代码质量不至于腐化到无可救药地步的有效手段，那么利用解耦的方法对代码重构，就是保证代码不至于复杂到无法控制的有效手段。
我们在第 22 讲有介绍，什么是“高内聚、松耦合”。如果印象不深，你可以再去回顾一下。实际上，“高内聚、松耦合”是一个比较通用的设计思想，不仅可以指导细粒度的类和类之间关系的设计，还能指导粗粒度的系统、架构、模块的设计。相对于编码规范，它能够在更高层次上提高代码的可读性和可维护性。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

解耦是软件设计与开发中至关重要的工作，通过封装、抽象、模块化和中间层来实现。其目的在于提高代码的可读性、可维护性和可测试性，实现代码高内聚、松耦合。判断代码是否需要解耦可通过观察修改代码是否会影响其他模块，以及绘制依赖关系图来衡量。解耦方法包括封装与抽象、引入中间层和模块化，以及遵循设计原则如单一职责原则、基于接口编程、依赖注入、多用组合少用继承、迪米特法则等。解耦思想在实际开发中随处可见，如Spring中的AOP和IOC，能实现业务与非业务代码、对象的构造和使用的解耦。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《设计模式之美》，新⼈⾸单¥98

立即购买

登录后留言

全部留言(94)

最新
精选

lyshrine
依赖注入是不是也算是组合？
作者回复: 是的，从不同的角度来讲的，实际上可以看做一回事
2020-01-13
2
11
时光守护者-基兰
解耦合耦合性低怎么区分呢？
作者回复: 这个不好定量来区分的
2020-08-10


lmdcx
必须留个言，倾诉倾诉。昨天晚上就因为看争哥直播，3岁儿子把 mac 的屏给我弄碎了，这一下子看直播的代价也太惨重了，5千多。重点是我还只看了个开头o(╥﹏╥)o
2020-01-10
21
173
0xABC
1. Spring中的事件监听机制，是解耦的设计，利用观察者模式 2. 微服务中服务注册与发现是解耦的设计，引入中间层注册中心来实现 3. 调用链路跟踪是解耦的设计，将调用链的收集和业务代码解耦，利用动态代理来实现 4. Ribbon的客户端负载均衡也能算是一种解耦的设计，利用策略模式和模版方法，解耦了具体的负载算法的实现，而且还可以自定义 5. 最近在了解Service Mesh，sidecar 的 Proxy 也算是解耦的设计，利用边车模式代理了服务间的网络通信、监控等和实际业务无关的通用逻辑 6. 。。。
2020-03-17
4
92
下雨天
消息队列，事件监听实现了被观察者和观察者的解耦！
2020-01-10
1
54
辣么大
docker 通过容器打包应用，解耦应用和运行平台。
2020-01-10

40
Ken张云忠
实际上，在我们平时的开发中，解耦的思想到处可见，比如，Spring 中的 AOP 能实现业务与非业务代码的解耦，IOC 能实现对象的构造和使用的解耦。除此之外，你还能想到哪些解耦的应用场景吗？解耦是人类应对复杂性问题的有效手段,解耦的核心是拆分,横向可以拆分出不同的模块,纵向可以拆分出不同的工序,然后就有了人类的大分工协作,分工协作可以把大规模的人有效组织起来参与社会大生产,最终推动社会生产力的进步. 解耦场景如国家机器的运转,国务院有国防部/人民银行/财政部/审计署/农业部/保障部/卫生部/教育部/司法部/交通部/水力部/建设部/信息产业部/计委等不同部门组成,另外各个地方政府又有一套完整的组织体系共同组成中国的政府系统.各部各司其职,如人民银行负责货币政策的调整,财政部负责税收政策的调整等. 企业的组织运转也是解耦的,企业内部不同的职能部门,如计财部/人力部/技术部/市场部/运营部. 技术部又有不同的岗位,如产品经理/UI/开发/测试/运维.
2020-01-10

23
李小四
设计模式_30 # 作业消息队列，作为观察者模式的的代表，极大程度地实现了解耦，也在很大程度上解决了资源有限时的高并发崩溃。我认为API的使用也算是一种解耦吧，将客户端与服务端，将不同模块的服务可以高效配合，但不关心对方的实现。现在的web项目普遍使用了前后端分离的方式，其实在这之前还有一种混合(耦合)的方式，前后端的代码在一个仓库中，前端的细微修改要发布整个项目，极容易出错。 # 感受我们现在技术，很大程度上解决了人脑解决不了的速度问题和复杂性问题，速度问题主要取决于硬件(只要代码不是特别糟)，复杂性问题就成了程序员的重大难题，因为它违反直觉，它的设计起来困难且更需要耐心。另外，可以开始复习了。。。文中提到的原则有些已经记不清要点了。
2020-01-10
2
22
scmath
AOP:“业务代码”和“非业务代码”解耦。 IOC：对象的“使用者”和“创建者”解耦。总结的精辟！
2020-05-22

11
饭粒
Linux 虚拟文件系统解耦系统调用和具体的文件系统实现；TCP/IP 网络协议分层。
2020-01-13

7

收起评论