软件设计之美
郑晔
推文科技技术 VP,前火币网首席架构师
19414 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 40 讲
软件设计之美
15
15
1.0x
00:00/00:00
登录|注册

05 | Spring DI容器:如何分析一个软件的模型?

你好!我是郑晔。
在上一讲中,我们讨论了如何了解一个软件的设计,主要是从三个部分入手:模型、接口和实现。那么,在接下来的三讲中,我将结合几个典型的开源项目,告诉你如何具体地理解一个软件的模型、接口和实现。
今天这一讲,我们就先来谈谈了解设计的第一步:模型。如果拿到一个项目,我们怎么去理解它的模型呢?
我们肯定要先知道项目提供了哪些模型,模型又提供了怎样的能力。这是所有人都知道的事情,我并不准备深入地去探讨。但如果只知道这些,你只是在了解别人设计的结果,这种程度并不足以支撑你后期对模型的维护。
在一个项目中,常常会出现新人随意向模型中添加内容,修改实现,让模型变得难以维护的情况。造成这一现象的原因就在于他们对于模型的理解不到位。
我们都知道,任何模型都是为了解决问题而生的,所以,理解一个模型,需要了解在没有这个模型之前,问题是如何被解决的,这样,你才能知道新的模型究竟提供了怎样的提升。也就是说,理解一个模型的关键在于,要了解这个模型设计的来龙去脉,知道它是如何解决相应的问题。
今天我们以 Spring 的 DI 容器为例,来看看怎样理解软件的模型。

耦合的依赖

Spring 在 Java 世界里绝对是大名鼎鼎,如果你今天在做 Java 开发而不用 Spring,那么你大概率会被认为是个另类。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件设计之美》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(38)

  • 最新
  • 精选
  • Moonus
    我觉得最根本原因是大多数开发不写测试,所以不会考虑依赖问题,大多数方法都是面向实现而不是接口,使用DI容器反而增加了工作量。 目前所在小组偏向于外包,代码只有一层,不是单列,就是静态方法;为了达到快速交付,基本没有设计,不管怎么说这都是不合理的。是前人挖,后人跳。

    作者回复: 唉,你说的现状,我非常理解。所谓的“快”,只是从当前一个时点上看,放在长期,就是越跑越慢。

    9
    23
  • 阳仔
    理解软件设计中模型首先要理解模型解决的核心问题是什么,然后抽丝剥茧了解模型的来龙去脉,深入理解模型解决问题的过程。 spring中的di模型是为了解决对象的创建和组装的问题。 那为什么创建对象和组装要用di来解决? 一个重要的原因是为了解耦。分离接口与实现的强依赖,也就是软件设计第一步分离关注点。 而这个恰恰就是为了可测试性,当一个代码是可测的,其实就是说明它是比较灵活的,修改起来不会牵一发而动全身,提高开发的体验,减少因修改引入的额外问题

    作者回复: 很好的总结。

    18
  • keep_curiosity
    为什么不建议使用静态方法?如果只是简单的模型转换,用静态方法不是更好吗?

    作者回复: 静态方法,没法去模拟它的行为,所以,要做测试的话,遇到静态方法,你必须关注它的实现,而不是它的接口。总的来说,静态方法是写着爽,但测着不方便。

    2
    12
  • 刘丹
    container.bind(Connection.class).to(connection); container.bind(ArticleReposistory.class).to(DBArticleRepository.class); container.bind(ArticleService.class).to(ArticleService.class) 请问这3行代码的具体含义是啥?

    作者回复: 将 Connection 这个类绑定在 connection 这个对象上,当需要一个 Connection 对象时,返回 connection 这个对象。 将 ArticleReposistory 这个接口绑定在 DBArticleRepository 这个类上,当需要一个 ArticleReposistory 对象时,返回 DBArticleRepository 这个类的一个对象。 将 ArticleService 这个类就绑定在其自身,当需要一个 ArticleService 对象时,返回这个类的一个对象。

    7
    10
  • JohnnyB0Y
    回答作业: 1,Java有反射,其他语言不一定有; 2,Java生态比较完善,大神比较多,有模版可以学; 3,前端开发集中在UI界面和数据解析,需求变更快,用DI容器去做有点吃力;(UI大多是包含的方式,很难把子控件拎出来初始化) 4,DI容器的AOP可能更适合后端,突如其来的统计、归档之类的需求。而前端的应用生命周期和页面生命周期都由UI框架提供了,AOP自然用的少。 总结:我觉得AOP可能才是开发者爱用DI的主要原因,加上Java生态的繁荣最终流行起来。(个人看法)

    作者回复: AOP 早在 DI 之前就有了,它并没有那么大的推动作用,DI 兴起之后,它才有了更多的用武之地。

    3
    9
  • 骨汤鸡蛋面
    接触spring 七八年, 一直在学习BeanFactory 和 ApplicationContext 上打转,今天才算对容器这个概念有一个直觉性的认识,感谢老师!

    作者回复: 学习一个软件,要从基础模型开始。

    7
  • 业余爱好者
    一个框架的流行根本原因不是它简化了开发,而是导致了问题的简化的那个开发模型。像spring 提供的di 模型,你甚至感受不到它的存在。它更像是一种理念,而这是一个模型的最高级形态。在di的核心模型之上,又出现了starter,auto configuration 等理念,这就是spring boot 的模型创新。在springboot 之上,又有springcloud..... Spring 这个框架,真的是,,,牛逼(找不到合适的词了)

    作者回复: 没错,简化开发是结果,模型才是动因。 Spring Boot 是在 Spring 出现好多年之后才出现的。

    2
    5
  • 六一王
    我是一个两年的前端程序媛,不太了解 java。面向对象编程时,你只想要一颗树,却得到整个森林,于是有些人就觉得面向对象编程是不好的,所以认为函数式编程的方式更好,不过文章提到的组件创建和组合放入到一个容器中,也就是说将所有依赖都放入都一个地方,提供业务需要的接口,而不写到业务中,那么为啥没有在前端火起来呢?函数式编程是不是就是面向接口编程的一种呢?

    作者回复: 后面会讲到函数式编程,简单来说,面向对象提供了组织类的能力,函数式编程提供了组织动作的能力,二者可以混合使用。

    4
  • 小鱼儿
    放下历史长河之中去看问题,比如 现在去看几年前甚至10年前的代码,才知道这样做的好处,分离关注点,可测试性是多么需要,不然真的改不动。

    作者回复: 这是我在开篇词里的立论,软件设计是一门关注长期变化的学问。

    3
    4
  • 迈步
    我的理解,IoC是一种思想,就像OOP、AOP一样都是思想。而DI是技术实现,是IoC的最常见以及最合理的实现方式。按照老马(Martin Fowler)的意思,可以使用DI代替掉IoC。因为DI就基本能够体现出IoC的意思了。省得搞混淆了。 另外对于静态方法,在日常开发中,老师的建议是什么呀?推荐使用吗?在什么场景下可以推荐使用?

    作者回复: IoC、DI、DIP 其实这几个名字在早先的讨论里是类似的,容易混淆的,其重点都是把依赖通过接口隔离开。最后 DI 容器这里选了 DI,后面我们会讲到 DIP,可以再来看。IoC 远远到不了 OO 的级别,只是一种设计原则。 静态方法能不用就不用,大多数情况下都可以用普通方法代替。只有少数程序库适合写成 static 的。

    2
    3
收起评论
显示
设置
留言
38
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部