Spring 框架是怎么出生的（二）：重构提炼出框架
source link: https://mp.weixin.qq.com/s/suSvyFuUl1SZjHN5MK5APQ
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
“ 代码重复就是机会。 ”
上一篇结束时， 我们给出这样的提问：
如果把创建对象和管理依赖的代码从Main.java中挪出到别的类中， 情况会怎样？ 会不会好一些？
版本2
这个提问的解答会帮助咱意识到， 这个问题是所有项目中的共性。如果能想一招儿， 降低模块之间耦合的话，我们实际上是搞了一个框架，这个框架可以帮助节省程序员的精力，也最终让模块的实现代码清爽易读。这里，我们自建的这个框架自然称之为“Apurav Framework”。
Apurav Framework的核心职责是读取对象定义文件，其中也定义了每一个对象的依赖。文件定义如下：
基于上面定义文件，解析并创建对象的代码如下：
上面代码的关键要点如下：
1. 读取配置文件。
2. 针对配置中以object开头的项，使用Class.forName加载到对应的Class后，创建相应的对象后， 放到HashMap的寄存器中。
3. 针对配置中非object开头的配置项，先从对象寄存器中找到对应的对象，再利用反射设置依赖。
经过上面的处理后，原有代码中创建对象及设置依赖的部分抽取提炼到ApuravFramework.java文件，我们Main.java文件中也就只剩下调用业务逻辑的单一功能， 清爽了很多。
上面代码中， 通过配置， ApuravFramework本质上看，将依赖的控制从Main.java文件中，迁移到自己身上。这样，这个小框架就是经常听到的IoC容器和DI框架。
嗯，对了， 这就是Spring框架里最核心的功能。
版本3：
最后的版本， 也就是直接使用Spring框架了。其内部， 也像ApuravFramework.java一样，生成对象后，再设置依赖。跟上面例子不同的是，这里是从XML配置文件中读取的， 而不是普通的配置文件。
至此， 我们从丑陋重复的代码开始，识别出除业务核心逻辑之外的支撑功能，并抽离出来，形成原始的IoC框架，最终过渡到标准的Spring框架使用。通过这个演化，从重构的角度，体会到了Spring框架是怎么出生的。当然，这样的重构过程， 不单单是Spring框架独有的， 希望这个演化带来的启发也能帮到咱们业务系统的重构和设计中，最终提升业务系统质量，并帮助业务创新。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK