设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
18959 人已学习
课程目录
已更新 33 讲 / 共 100 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训,让你告别没有成长的烂代码!
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识?
02 | 从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?
03 | 面向对象、设计原则、设计模式、编程规范、重构,这五者有何关系?
设计原则与思想:面向对象 (11讲)
04 | 理论一:当谈论面向对象的时候,我们到底在谈论什么?
05 | 理论二:封装、抽象、继承、多态分别可以解决哪些编程问题?
06 | 理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗?
07 | 理论四:哪些代码设计看似是面向对象,实际是面向过程的?
08 | 理论五:接口vs抽象类的区别?如何用普通的类模拟抽象类和接口?
09 | 理论六:为什么基于接口而非实现编程?有必要为每个类都定义接口吗?
10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?
11 | 实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?
12 | 实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?
13 | 实战二(上):如何对接口鉴权这样一个功能开发做面向对象分析?
14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?
设计原则与思想:设计原则 (12讲)
15 | 理论一:对于单一职责原则,如何判定某个类的职责是否够“单一”?
16 | 理论二:如何做到“对扩展开放、修改关闭”?扩展和修改各指什么?
17 | 理论三:里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?
18 | 理论四:接口隔离原则有哪三种应用?原则中的“接口”该如何理解?
19 | 理论五:控制反转、依赖反转、依赖注入,这三者有何区别和联系?
20 | 理论六:我为何说KISS、YAGNI原则看似简单,却经常被用错?
21 | 理论七:重复的代码就一定违背DRY吗?如何提高代码的复用性?
22 | 理论八:如何用迪米特法则(LOD)实现“高内聚、松耦合”?
23 | 实战一(上):针对业务系统的开发,如何做需求分析和设计?
24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?
25 | 实战二(上):针对非业务的通用框架开发,如何做需求分析和设计?
26 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?
设计原则与思想:规范与重构 (4讲)
27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?
28 | 理论二:为了保证重构不出错,有哪些非常能落地的技术手段?
29 | 理论三:什么是代码的可测试性?如何写出可测试性好的代码?
30 | 理论四:如何通过封装、抽象、模块化、中间层等解耦代码?
不定期加餐 (2讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
设计模式之美
登录|注册

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

王争 2020-01-10
前面我们讲到,重构可以分为大规模高层重构(简称“大型重构”)和小规模低层次重构(简称“小型重构”)。大型重构是对系统、模块、代码结构、类之间关系等顶层代码设计进行的重构。对于大型重构来说,今天我们重点讲解最有效的一个手段,那就是“解耦”。解耦的目的是实现代码高内聚、松耦合。关于解耦,我准备分下面三个部分来给你讲解。
“解耦”为何如此重要?
如何判定代码是否需要“解耦”?
如何给代码“解耦”?
话不多说,现在就让我们正式开始今天的学习吧!

“解耦”为何如此重要?

软件设计与开发最重要的工作之一就是应对复杂性。人处理复杂性的能力是有限的。过于复杂的代码往往在可读性、可维护性上都不友好。那如何来控制代码的复杂性呢?手段有很多,我个人认为,最关键的就是解耦,保证代码松耦合、高内聚。如果说重构是保证代码质量不至于腐化到无可救药地步的有效手段,那么利用解耦的方法对代码重构,就是保证代码不至于复杂到无法控制的有效手段。
我们在第 22 讲有介绍,什么是“高内聚、松耦合”。如果印象不深,你可以再去回顾一下。实际上,“高内聚、松耦合”是一个比较通用的设计思想,不仅可以指导细粒度的类和类之间关系的设计,还能指导粗粒度的系统、架构、模块的设计。相对于编码规范,它能够在更高层次上提高代码的可读性和可维护性。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(27)

  • Geek_Zjy
    必须留个言,倾诉倾诉。
    昨天晚上就因为看争哥直播,3岁儿子把 mac 的屏给我弄碎了,这一下子看直播的代价也太惨重了,5千多。
    重点是我还只看了个开头o(╥﹏╥)o
    2020-01-10
    3
    11
  • 下雨天
    消息队列,事件监听实现了被观察者和观察者的解耦!
    2020-01-10
    9
  • 李小四
    设计模式_30
    # 作业
    消息队列,作为观察者模式的的代表,极大程度地实现了解耦,也在很大程度上解决了资源有限时的高并发崩溃。
    我认为API的使用也算是一种解耦吧,将客户端与服务端,将不同模块的服务可以高效配合,但不关心对方的实现。现在的web项目普遍使用了前后端分离的方式,其实在这之前还有一种混合(耦合)的方式,前后端的代码在一个仓库中,前端的细微修改要发布整个项目,极容易出错。

    # 感受
    我们现在技术,很大程度上解决了人脑解决不了的速度问题和复杂性问题,速度问题主要取决于硬件(只要代码不是特别糟),复杂性问题就成了程序员的重大难题,因为它违反直觉,它的设计起来困难且更需要耐心。

    另外,可以开始复习了。。。文中提到的原则有些已经记不清要点了。
    2020-01-10
    1
    5
  • Jeff.Smile
    重构是术与道的结合,道为重构的思路,指南。术是具体的手段!
    2020-01-10
    1
    2
  • 辣么大
    docker 通过容器打包应用,解耦应用和运行平台。
    2020-01-10
    1
  • 王涛
    代码解耦的第二种方式,中间层。
    上层代码都依赖中间层代码,中间层也是使用基于借口而非实现编程。
    抽象出中间层肯定是好的,但这样是否也会带来另一个问题: 中间层接口变动必然会影响所有上层代码调用,接口的影响面是否是变大了?如果是的话,下一步有该怎么优化呢?
    2020-01-10
    1
  • 桂城老托尼
    通过消息中间件实现的生产与消费的解耦;
    通过SPI回调实现的主流程与个性化编排实现的解耦;
    同步调用改为异步调用理论上也算调用与被调用的解耦;
    2020-01-10
    1
  • 平风造雨
    消息列队,事件驱动,都是典型的解耦。
    2020-01-11
  • Frank
    目前能想到的解耦手段有以下两个:
    1. 引入消息中间件实现业务系统之间的解耦;
    2. 分层思想,如MVC思想,网络的OSI七层参考模型;
    2020-01-11
  • 黄林晴
    打卡✔
    2020-01-10
  • 编程界的小学生
    中间件也可以解耦,MVC架构也是解耦。
    2020-01-10
  • 此鱼不得水
    大佬多来一些例子哈哈
    2020-01-10
  • Jxin
    1.防腐层,解耦本地服务和远程服务的api依赖。但这不过是中间层的一种落地范式,其核心原则也属于设计原则中的迪米乐和接口隔离(由api客服端实现)。

    2.事件机制,解决跨服务的事务操作依赖。常规范式就是mq了。(进程级的事件机制也有,但分布式场景很少用,毕竟mq能做的进程级事件不一定能做比如消息持久化,进程级事件能做的mq都能做)

    3.镜像,重新定义发布单元。解决可执行代码和运行环境的依赖。容器的事实标准就是docker,而编排主流则是k8s。
    2020-01-10
  • DullBird
    Mq消息通知,数据缓存通过mysql binlog监听更新, 数据的领域层serivce,和业务service之间的调用关系,spring security中authentication实现和Session的解耦
    2020-01-10
  • 睡觉💤
    之前做过一个电商系统。交易需要记录在区块链上。当时采用的就是解耦的思想。电商系统还是负责原有的业务。通过rpc将交易数据传递到区块链服务进行入链业务。
    2020-01-10
  • 逍遥思
    文中举的那个利用中间层让重构和开发不冲突的例子里:第一阶段:引入一个中间层,包裹老的接口,提供新的接口定义。
    这里的“提供新的接口定义”,新接口直接就可用了吗?
    2020-01-10
  • 守拙
    解耦的目的是维持系统中组件之间的交互关系清晰.

    封装与抽象,中间层,模块化及各种设计思想是解耦的手段.

    解耦的最终诉求是系统的可维护性.

    课堂讨论:
    解耦最常见的应用场景是事件总线(EventBus)
    EventBus通过引入中间件的手段, 使事件(Event)的发布者(Publisher)与事件的订阅者(Subscriber)解耦.
    如果没有EventBus,就会造成Publisher与Subscriber强耦合.

    除此以外, 依赖注入(Dependency Injection)也是常见的解耦手段.

    2020-01-10
  • 天意林
    设计原则目的为了提高代码质量,设计模式可以理解为是为了达到设计原则要求的一种技术手段,比如观察者模式、命令模式、代理模式等都可以有效的降低代码耦合度。
    2020-01-10
  • Ken张云忠
    实际上,在我们平时的开发中,解耦的思想到处可见,比如,Spring 中的 AOP 能实现业务与非业务代码的解耦,IOC 能实现对象的构造和使用的解耦。
    除此之外,你还能想到哪些解耦的应用场景吗?
    解耦是人类应对复杂性问题的有效手段,解耦的核心是拆分,横向可以拆分出不同的模块,纵向可以拆分出不同的工序,然后就有了人类的大分工协作,分工协作可以把大规模的人有效组织起来参与社会大生产,最终推动社会生产力的进步.
    解耦场景如国家机器的运转,国务院有国防部/人民银行/财政部/审计署/农业部/保障部/卫生部/教育部/司法部/交通部/水力部/建设部/信息产业部/计委等不同部门组成,另外各个地方政府又有一套完整的组织体系共同组成中国的政府系统.各部各司其职,如人民银行负责货币政策的调整,财政部负责税收政策的调整等.
    企业的组织运转也是解耦的,企业内部不同的职能部门,如计财部/人力部/技术部/市场部/运营部.
    技术部又有不同的岗位,如产品经理/UI/开发/测试/运维.
    2020-01-10
  • 啦啦啦
    laravel的服务提供者
    2020-01-10
收起评论
27
返回
顶部