“ 代码重复就是机会。 ”
上一篇结束时, 我们给出这样的提问:
如果把创建对象和管理依赖的代码从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框架独有的, 希望这个演化带来的启发也能帮到咱们业务系统的重构和设计中,最终提升业务系统质量,并帮助业务创新。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Spring 框架是怎么出生的(二):重构提炼出框架
- UWeb v1.0.9 发布,重构框架基类
- Golang实现简单爬虫框架(5)——项目重构与数据存储
- Java 微服务框架 Jeecg-P3 1.0.0 重构版本发布
- 牌类游戏使用微服务重构笔记(三): micro框架简介 go-micro
- 从零开始Gin Web+Vue商城的搭建(四)-- 重构用户模块和框架设计
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。