为什么 spring 源码中类的关系那么复杂?

[BlackZhu]

最近在读 spring 源码,发现其中的类关系真让人头大,一层一层的继承实现太繁杂了,比如一个抽象方法往往要往下走好几层才会有具体的实现!
这是 spring 本身的设计理念,还是随着项目的发展迭代出来的结果?

[bthulu]

迭代了 N 年的结果啊, 当年比较注重面向对象, 各种设计模式来一遍, 自然是一层套一层越套越多了

[thinkershare]

因为计算机科学中, 没有什么问题是通过添加一个抽象无法解决的, 如果不行, 就再加一个抽象. 所以后来有了: 如无必要、勿增实体. 而什么是必要就是一个哲学问题了! 每一个添加的抽象都是为了某个切面需求概率的抽象.

[forgottencoast]

应该要研究他这样做的意义。

[BlackZhu]

@bthulu 所以说这算是一种缺陷? 如果官方团队有机会重构的话 会放弃这种理念 选择更加精简的方式吗


@forgottencoast 我就是不太懂这样做的意义 在自己的项目中也有必要采用这种设计方式吗? 对项目是好处大还是坏处大?

[thinkershare]

@BlackZhu 如果你的项目中, 你无法搞清楚抽象的目的, 就不要抽象. 每个人都只能试图看的稍微远一点, 预测非常永久的事情纯粹是赌运气. 抽象是有代价的, 你需要了评估你项目的复杂度, 没有一个放之四海而皆准的办法, 设计就是平衡矛盾的需求, 平衡的好, 就是有效设计.

[thinkershare]

另外你说的 Spring 的抽象设计在它的体系中是没啥问题的! 官方团队即便重构大差不大还是这个样子, 除非需求发生了重大变化, 软件设计就是尽量让代码贴近需求的自然抽象, 越是自然, 则未来越是容易维护和扩展!

[ikas]

spring 曾经是相对于 javaee 的轻量级框架..
当时随着应用的广泛,必然会增加各种需求啊..才逐渐形成了如今的样子..

[Braisdom]

Sping 是一个高度抽象的框架，为了适应各种系统的需求，才会产生各种抽象，本质上是为了适应变化，但这样做也是有成本的，也就是导致框架代码很难理解，各种抽象概念、各种关系起来越复杂。天下大事，分久必合，合久必分，现在一些比较轻量级的框架也在产生。

[haha512]

过度设计，都其他为项目准备勾画好了未来 20 年的需要
但实际 99%的项目不到 5 年都死了或者重构了(哈哈

[murmur]

@haha512 初始版本：2002 年 10 月 1 日，也就是说很快 spring 就迎来 20 年生日了

[zoharSoul]

spring 的风格, 你看 golang 的很多框架就没这么玩

[FreeEx]

所以我都不读源码，这些框架都不是一次性写好的，而是经过了大量时间缝缝补补，Spring 当年相对 EJB 也算轻量，现在也变成了一个庞然大物，屠龙勇士终成恶龙？

[FrankHB]

@thinkershare 显然有，比如抽象太多并且泄露出来被用户发现了的这种 OP 问题。

[slyang5]

@zoharSoul 只能说 go 的框架还不成熟, 面向的用户还不够大众

[thinkershare]

@FrankHB 他去看源代码, 当然任何实现细节都会被发现!

[bigbyto]

源码不是这样读的，先看借口抽象文档，再看细节实现。理解了接口，就不会觉得复杂。

[shyangs]

Java 好像有這種一層套一層的梗圖 /搞笑圖，版友有存的可以貼上來.

[nothingistrue]

面向对象编程第一个解决的问题：让开发类库的人和使用类库的人可以分开。开发 Spring ，和使用 Spring 开发业务，一个是开发类库，一个是使用类库开发业务，你不能那一个标准去看源码。

[frank1256]

20 年的代码，能看懂已经不复杂了

[git00ll]

拿当初 spring1 的代码放到现在 spring5 里面，仍然兼容。
这不正是说明设计的很棒吗