Spring框架是怎么出生的（二）：重构提炼出框架
“ 代码重复就是机会。”
上一篇结束时， 我们给出这样的提问：
如果把创建对象和管理依赖的代码从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框架独有的， 希望这个演化带来的启发也能帮到咱们业务系统的重构和设计中，最终提升业务系统质量，并帮助业务创新。
---------
往期推荐
~~~~~~~~~~~~~
长按二维码，关注公众号
一起推进电商业务信息化