IOC 实现原理
2015-11-10 15:51
197 查看
本文是《轻量级
Java Web 框架架构设计》的系列博文。
IOC 也就是“控制反转”了,不过更流行的叫法是“依赖注入”(DI - Dependency Injection)。听起来挺高深,其实实现起来并不复杂。下面就看看如何来实现这个轻量级 IOC 框架。
从实例出发,先看看以下 Action 代码。
?
以上使用了两个自定义注解:@Bean 与 @Inject。
在 ProductAction 类上标注了 @Bean 注解,表示该类会交给“容器”处理,以便加入依赖注入框架。
在 produceService 字段上标注了 @Inject 注解,表示该字段将会被注入进来,而无需 new ProductServiceImpl(),实际上 new 这件事情不是我们做的,而是框架做的,也就是说控制权正好反过来了,所以“依赖注入(DI)”也称作“控制反转(IoC)”。
那么,应该如何实现依赖注入框架呢?首先还是看看下面的 BeanHelper 类吧。
?
其实很简单,依赖注入其实分为两个步骤:1. 通过反射创建实例;2. 获取需要注入的接口实现类并将其赋值给该接口。以上代码中的两个 for 循环就是干这两件事情的。
依赖注入框架实现完毕!
请大家给出评价,谢谢!
补充(2013-09-05)
有些网友对如何寻找接口的实现类的算法有些疑问,如果一个接口存在两个实现类,应该获取哪一个实现类呢?我之前的做法是,只获取第一个实现类。而 Spring 的做法是,直接报错,应用都起不来。经过反复思考,我做了一个慎重的决定,就是在接口上使用 @Impl 注解来强制指定哪个实现类。而 BeanHelper 在做依赖注入的时候,会首先判断接口上是否有 @Impl 注解,如果有就获取这个强制指定的实现类实例,否则就获取所有实现类中的第一个实现类,仍然不会像 Spring 那样让应用报错。下面是对 BeanHelper
类中部分代码的修改:
?
在接口中是这样使用的:
?
假设这个接口的实现类是 ProductServiceImpl2。
这个解决方案相信大家还是满意的吧?
补充(2013-09-12)
大家上面看到的 BeanHelper 类,其实兼任了两种职责:1.初始化所有的 Bean 类;2.实现依赖注入。
这违法了设计模式中的“单一责任原则”,所有有必要将其重构一下,现在的 BeanHelper 类更加苗条了,只是负责初始化 Bean 类而已。代码如下:
?
那么,依赖注入功能放哪里呢?我搞了一个 IOCHelper,用这个类来实现 IOC 功能。代码如下:
?
可见,IOCHelper 是依赖于 BeanHelper 的。这样分离,还有一个好处,就是方便实现 ServiceHelper 与 AOPHelper。也就是说,首先通过 BeanHelper 初始化所有的 Bean 类,然后依次初始化 ServiceHelper、IOCHelper、AOPHelper,这个顺序不能搞错。因为在
ServcieHelper 中,对 Servcie 实现类进行了动态代理,所有保证了 IOC 注入进来的是代理类,而并非目标类。
在 AOPHelper 中也做了动态代理的实现,详情请见《AOP 实现原理》。
转载:http://my.oschina.net/huangyong/blog/158992
Java Web 框架架构设计》的系列博文。
IOC 也就是“控制反转”了,不过更流行的叫法是“依赖注入”(DI - Dependency Injection)。听起来挺高深,其实实现起来并不复杂。下面就看看如何来实现这个轻量级 IOC 框架。
从实例出发,先看看以下 Action 代码。
?
在 ProductAction 类上标注了 @Bean 注解,表示该类会交给“容器”处理,以便加入依赖注入框架。
在 produceService 字段上标注了 @Inject 注解,表示该字段将会被注入进来,而无需 new ProductServiceImpl(),实际上 new 这件事情不是我们做的,而是框架做的,也就是说控制权正好反过来了,所以“依赖注入(DI)”也称作“控制反转(IoC)”。
那么,应该如何实现依赖注入框架呢?首先还是看看下面的 BeanHelper 类吧。
?
依赖注入框架实现完毕!
请大家给出评价,谢谢!
补充(2013-09-05)
有些网友对如何寻找接口的实现类的算法有些疑问,如果一个接口存在两个实现类,应该获取哪一个实现类呢?我之前的做法是,只获取第一个实现类。而 Spring 的做法是,直接报错,应用都起不来。经过反复思考,我做了一个慎重的决定,就是在接口上使用 @Impl 注解来强制指定哪个实现类。而 BeanHelper 在做依赖注入的时候,会首先判断接口上是否有 @Impl 注解,如果有就获取这个强制指定的实现类实例,否则就获取所有实现类中的第一个实现类,仍然不会像 Spring 那样让应用报错。下面是对 BeanHelper
类中部分代码的修改:
?
?
这个解决方案相信大家还是满意的吧?
补充(2013-09-12)
大家上面看到的 BeanHelper 类,其实兼任了两种职责:1.初始化所有的 Bean 类;2.实现依赖注入。
这违法了设计模式中的“单一责任原则”,所有有必要将其重构一下,现在的 BeanHelper 类更加苗条了,只是负责初始化 Bean 类而已。代码如下:
?
?
ServcieHelper 中,对 Servcie 实现类进行了动态代理,所有保证了 IOC 注入进来的是代理类,而并非目标类。
在 AOPHelper 中也做了动态代理的实现,详情请见《AOP 实现原理》。
转载:http://my.oschina.net/huangyong/blog/158992
相关文章推荐
- Android与Mysql服务器通信
- c++(爬楼梯)
- Faster-rnnlm代码分析3 - EvaluateLM(前向计算ForwardPropagate)
- GemFire读写示例
- 使用ComponentName启动Activity
- Leetcode TOP Questions
- 四种修饰符。
- iOS常识总结
- WebService 在javaEE中的应用
- 【译】17个提升iOS开发效率的必用工具
- Android与Mysql服务器通信
- Android之zxing二维码生成与识别
- 使用xcode storyboard设置按钮圆角方法
- 关联数组
- git 自动部署
- CCS中CMD文件解析
- Android Shape自定义纯色圆角按钮
- 3 最小BLE应用简介
- Play framework 2.0 -模板引擎
- Groovy 插件安装不成功