这是一个创建于 1001 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在读 spring 源码,发现其中的类关系真让人头大,一层一层的继承实现太繁杂了,比如一个抽象方法往往要往下走好几层才会有具体的实现!
这是 spring 本身的设计理念,还是随着项目的发展迭代出来的结果?
这是 spring 本身的设计理念,还是随着项目的发展迭代出来的结果?
 |
1
bthulu 2022-03-26 20:52:11 +08:00
迭代了 N 年的结果啊, 当年比较注重面向对象, 各种设计模式来一遍, 自然是一层套一层越套越多了
|
 |
2
thinkershare 2022-03-26 20:57:40 +08:00
因为计算机科学中, 没有什么问题是通过添加一个抽象无法解决的, 如果不行, 就再加一个抽象. 所以后来有了: 如无必要、勿增实体. 而什么是必要就是一个哲学问题了! 每一个添加的抽象都是为了某个切面需求概率的抽象.
|
 |
3
forgottencoast 2022-03-26 21:05:36 +08:00
应该要研究他这样做的意义。
|
 |
4
BlackZhu OP @bthulu 所以说这算是一种缺陷? 如果官方团队有机会重构的话 会放弃这种理念 选择更加精简的方式吗
@forgottencoast 我就是不太懂这样做的意义 在自己的项目中也有必要采用这种设计方式吗? 对项目是好处大还是坏处大? |
|
5
thinkershare 2022-03-26 21:34:10 +08:00  1
@BlackZhu 如果你的项目中, 你无法搞清楚抽象的目的, 就不要抽象. 每个人都只能试图看的稍微远一点, 预测非常永久的事情纯粹是赌运气. 抽象是有代价的, 你需要了评估你项目的复杂度, 没有一个放之四海而皆准的办法, 设计就是平衡矛盾的需求, 平衡的好, 就是有效设计.
|
|
6
thinkershare 2022-03-26 21:36:09 +08:00
另外你说的 Spring 的抽象设计在它的体系中是没啥问题的! 官方团队即便重构大差不大还是这个样子, 除非需求发生了重大变化, 软件设计就是尽量让代码贴近需求的自然抽象, 越是自然, 则未来越是容易维护和扩展!
|
 |
7
ikas 2022-03-26 23:25:24 +08:00
spring 曾经是相对于 javaee 的轻量级框架..
当时随着应用的广泛,必然会增加各种需求啊..才逐渐形成了如今的样子.. |
 |
8
Braisdom 2022-03-27 09:31:36 +08:00
Sping 是一个高度抽象的框架，为了适应各种系统的需求，才会产生各种抽象，本质上是为了适应变化，但这样做也是有成本的，也就是导致框架代码很难理解，各种抽象概念、各种关系起来越复杂。天下大事，分久必合，合久必分，现在一些比较轻量级的框架也在产生。
|
 |
9
haha512 2022-03-27 14:37:02 +08:00
过度设计，都其他为项目准备勾画好了未来 20 年的需要
但实际 99%的项目不到 5 年都死了或者重构了(哈哈 |
 |
11
zoharSoul 2022-03-27 15:57:21 +08:00
spring 的风格, 你看 golang 的很多框架就没这么玩
|
 |
12
FreeEx 2022-03-27 17:09:12 +08:00
所以我都不读源码，这些框架都不是一次性写好的，而是经过了大量时间缝缝补补，Spring 当年相对 EJB 也算轻量，现在也变成了一个庞然大物，屠龙勇士终成恶龙？
|
 |
13
FrankHB 2022-03-27 17:22:03 +08:00
@thinkershare 显然有，比如抽象太多并且泄露出来被用户发现了的这种 OP 问题。
|
|
15
thinkershare 2022-03-27 21:38:15 +08:00
@FrankHB 他去看源代码, 当然任何实现细节都会被发现!
|
 |
16
bigbyto 2022-03-27 21:58:18 +08:00 1
源码不是这样读的，先看借口抽象文档，再看细节实现。理解了接口，就不会觉得复杂。
|
 |
17
shyangs 2022-03-28 00:44:35 +08:00
Java 好像有這種一層套一層的梗圖 /搞笑圖，版友有存的可以貼上來.
|
 |
18
nothingistrue 2022-03-28 10:01:50 +08:00
面向对象编程第一个解决的问题：让开发类库的人和使用类库的人可以分开。开发 Spring ，和使用 Spring 开发业务，一个是开发类库，一个是使用类库开发业务，你不能那一个标准去看源码。
|
 |
19
frank1256 2022-03-28 16:12:41 +08:00
20 年的代码，能看懂已经不复杂了
|
 |
20
git00ll 2022-03-28 17:24:28 +08:00
拿当初 spring1 的代码放到现在 spring5 里面，仍然兼容。
这不正是说明设计的很棒吗 |
 |
21
jeesk 2022-04-18 00:03:49 +08:00 via Android 4
我以前关注过一个公众号， 说是要读就从 spring 0.9 开始读， 当时我觉得他是垃圾。 两年后过去了，我觉得他很牛，现在才知道别人是在 oracle 和 ibm 呆过的大神。 因为 spring 就是 管理和创建 bean ，依赖注入 解决依赖循环， 其它的无非是 spring 的拓展。 我第一个框架阅读是的 google juice 的源码，第一个版本只有 20 个类， 我 debug 了一天才看懂基本原理。 又用了一天，看看懂了设计模式， 现在想想要是大牛早点说服我，我至少进步好几年。spring 无非也是这样， 第一个版本的 beanfactory 现在还在用， 所以你把 spring 0.9 的源码读了， 再去循序渐进的看 spring 5.0 的源码就简单多了。 因为原理你在 0.9 就知道了，其它的无非就是拓展。 即使是 spring 的作者现在也不一定能马上看懂了。 你给自己写个目标， 先.09 看， 再 2.0 ，3.0 ， 循序渐进， 我敢打赌 你看完能虐面试官
|
|
22
jeesk 2022-04-18 00:07:18 +08:00 via Android
所有的源代码都是从第一个版本看的， 这样看还可以让你明白， 为什么代码会改成这样， 有种豁然开朗的感觉我。 😁。 用这个方法我已经把 spring ，tomcat .h2database, mybatis 弄熟了。 你这样玩下去， 面试官随便虐。 太有成就感了。
|
|
23
jeesk 2022-04-18 00:16:18 +08:00 via Android
@Braisdom 我们项目在 storm 和 flink 用的是 juice ， 很轻量。 老大不让用 spring ， 依赖难搞。 现在用得爽得一批。
|
 |
25
zardmyLove 2023-02-05 11:08:44 +08:00
@jeesk 大佬，很好的想法啊，我去试试，能和大佬交流一下吗
|
|
26
jeesk 2023-02-05 13:04:19 +08:00
@zardmyLove 加我 wechatid(base64): bGlua3NoaXJsZXk=
|
Select Language