软件设计之美
郑晔
推文科技技术VP,前火币网首席架构师
立即订阅
3411 人已学习
课程目录
已更新 35 讲 / 共 36 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 软件设计,应对需求规模的“算法”
免费
课前必读 (3讲)
01 | 软件设计到底是什么?
02 | 分离关注点:软件设计至关重要的第一步
03 | 可测试性: 一个影响软件设计的重要因素
了解一个软件的设计 (4讲)
04 | 三步走:如何了解一个软件的设计?
05 | Spring DI容器:如何分析一个软件的模型?
06 | Ruby on Rails:如何分析一个软件的接口?
07 | Kafka:如何分析一个软件的实现?
设计一个软件—程序设计语言 (5讲)
08 | 语言的模型:如何打破单一语言局限,让设计更好地落地?
09 | 语言的接口:语法和程序库,软件设计的发力点
10 | 语言的实现:运行时,软件设计的地基
11 | DSL:你也可以设计一门自己的语言
加餐 | 再八卦几门语言!
设计一个软件—编程范式 (9讲)
12 | 编程范式:明明写的是Java,为什么被人说成了C代码?
13 | 结构化编程:为什么做设计时仅有结构化编程是不够的?
14 | 面向对象之封装:怎样的封装才算是高内聚?
15 | 面向对象之继承:继承是代码复用的合理方式吗?
16 | 面向对象之多态:为什么“稀疏平常”的多态,是软件设计的大杀器?
17 | 函数式编程:不用函数式编程语言,怎么写函数式的程序?
18 | 函数式编程之组合性:函数式编程为什么如此吸引人?
19 | 函数式编程之不变性:怎样保证我的代码不会被别人破坏?
加餐 | 函数式编程拾遗
设计一个软件—设计原则与模式 (7讲)
20 | 单一职责原则:你的模块到底为谁负责?
21 | 开放封闭原则:不改代码怎么写新功能?
22 | Liskov替换原则:用了继承,子类就设计对了吗?
23 | 接口隔离原则:接口里的方法,你都用得到吗?
24 | 依赖倒置原则:高层代码和底层代码,到底谁该依赖谁?
25 | 设计模式:每一种都是一个特定问题的解决方案
26 | 简单设计:难道一开始就要把设计做复杂吗?
设计一个软件—设计方法 (3讲)
27 | 领域驱动设计:如何从零开始设计一个软件?
28 | 战略设计:如何划分系统的模块?
29 | 战术设计:如何像写故事一样找出模型?
巩固篇 (3讲)
30 | 程序库的设计:Moco是如何解决集成问题的?
31 | 应用的设计:如何设计一个数据采集平台?
32 | 应用的改进:如何改进我们的软件设计?
软件设计之美
15
15
1.0x
00:00/00:00
登录|注册

24 | 依赖倒置原则:高层代码和底层代码,到底谁该依赖谁?

郑晔 2020-07-22
你好!我是郑晔。
上一讲,我们讲了 ISP 原则,知道了在设计接口的时候,我们应该设计小接口,不应该让使用者依赖于用不到的方法。但在结尾的时候,我留下了一个尾巴,说在那个例子里面还有一个根本性的问题:依赖方向搞反了。
依赖这个词,程序员们都好理解,意思就是,我这段代码用到了谁,我就依赖了谁。依赖容易有,但能不能把依赖弄对,就需要动点脑子了。如果依赖关系没有处理好,就会导致一个小改动影响一大片,而把依赖方向搞反,就是最典型的错误。
那什么叫依赖方向搞反呢?这一讲我们就来讨论关于依赖的设计原则:依赖倒置原则。

谁依赖谁

依赖倒置原则(Dependency inversion principle,简称 DIP)是这样表述的:
高层模块不应依赖于低层模块,二者应依赖于抽象。
High-level modules should not depend on low-level modules. Both should depend on abstractions.
抽象不应依赖于细节,细节应依赖于抽象。
Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件设计之美》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥19.9
立即订阅
登录 后留言

精选留言(13)

  • 人间四月天
    非常赞同!
    如果把设计原则,设计模式,结合一个开源框架讲解就更到位了,如果自己实现一个具体的框架,在把这些原则和模式结合进去,作为评价这个具体框架的依据,就会理解的非常通透。
    2020-07-22
    1
    4
  • 桃子-夏勇杰
    前后端团队经常因为接口变动而延误工期,这个接口到底由谁负责会靠谱一些?前端经常因为后端的接口未实现而延误某个功能,后端则因为对于其他依赖的系统而无法确定和实现接口。

    作者回复: 先确定接口再开发。

    2020-07-30
    3
  • Jxin
    防腐层可以解耦对外部系统的依赖。包括接口和参数。防腐层还可以贯彻接口隔离的思想,以及做一些功能增强(加缓存,异步并发取值)。

    作者回复: 没错!

    2020-07-22
    3
  • 阳仔
    依赖倒置原则说的是:
    1.高层模块不应依赖于低层模块,二者都应依赖于抽象
    2.抽象不应依赖于细节,细节应依赖于抽象
    总结起来就是依赖抽象(模型),具体实现抽象接口,然后把模型代码和组装代码分开,这样的设计就是分离关注点,将不变的与不变有效的区分开

    作者回复: 总结得好!

    2020-07-22
    3
  • 魂淡
    老师能不能推荐一些项目,或者框架什么的,去研究和实践老师说的这些理论,听了这么多理论,已经热血沸腾,迫不及待的实践一番!

    作者回复: 如果你想去研究开源项目,我推荐 Spring 框架、Google Guava 和我的 Moco。

    2020-07-28
    2
  • OlafOO
    老师你好,请教下开头的例子,step1和step2如果是接口,还有问题么;像这种流程式的代码还挺常见的

    作者回复: 有问题,你无法确定真的是Step1和Step2,还会不会有Step3,这个设计是不好的。如果你的设计是多个Step,这也许是一个更好的设计。

    2020-07-29
    1
  • private MessageSender sender;
      
      void execute() {
        ...
        Message message = ...;
        sender.send(message);
    这是啥语言可以这样写?php好像不可以吧?

    作者回复: 这是Java语言的实例代码。

    2020-07-23
    1
  • 大雁小鱼
    防腐层就是做隔离,一般用于系统集成中,新系统与旧系统集成,为了不让改变扩散,在系统之间多了一个层,叫防腐层,用于控制修改扩散,防腐层也有抽象对方系统的味道。
    2020-07-22
    1
  • 不记年
    感觉TransactionRequest只是存储了数据, 没必要要在抽象出一个接口来吧

    作者回复: 这里的关键在于隔离,虽然它是一个数据类,但在不同的地方扮演了不同的角色。

    2020-07-22
    1
  • 怎么才能不动调用代码,而只新建一个类,这才比较好
    2020-07-23
  • 声明以后还得去创交具体的累,将来提换的时候,还得改调用类的创建代码,感觉架构上还是有影响
    2020-07-23
  • Demon.Lee
    1、面向接口编程以及思考题中的防腐层(Anti-Corruption Layer)应该都算作是DIP下的一种具体方案或一种手段。

    2、“理解了 DIP,再来使用 DI 容器,你会觉得一切顺理成章,因为依赖之所以可以注入,是因为我们的设计遵循了 DIP。而只知道 DI 容器不了解 DIP,时常会出现让你觉得很为难的模型组装,根本的原因就是设计没有做好。”
    一时没想明白,又反复把本文和第05讲看了2遍,新的理解是:
    1)DIP设计模型之间的依赖关系,关注抽象,而不是具体的实现类。
    2)DI容器负责创建和组装具体的实现类,比如通过一个环境变量的值来判断,在config文件中具体实例化哪个类;因为业务代码中都是抽象接口,所以DI容器根据对应的名字或类型,将前面实例化的具体实现类,注入到业务代码中,程序员无感知。
    3)很为难的模型组装?没有想到好的例子,05讲中的例子,好像也不算DI容器的中为难的模型组装,老师有更好例子吗?

    以上,请老师指正。
    2020-07-23
  • qinsi
    “任何类都不应继承自具体类”和“任何方法都不应该改写父类中已经实现的方法”,放在一起是说,类可以继承自抽象类,但不应该改写抽象类中已实现的方法吗?因为如果类都只是依赖和实现接口的话,就没有所谓的继承和父类中的实现了。
    2020-07-22
收起评论
13
返回
顶部