浅谈IOC编程思想
为什么写IOC
在编程中经常用到IOC这种思想,比如Spring中使用注解@Autowire
或者@Resource
等注解就可以直接生成一个对象。虽然十分的方便但是这种思想是如何产生的?
IOC起源
我网上查找的资料就是Michael Mattson 在 1996年发布的《Object Oriented Frameworks: a survey on methodological issues》论文中最先提出的,并且他第96页的结论中写到。
An object-oriented framework is “a (generative) architecture designed for maximum reuse, represented as a collective set of abstract and concrete classes; encapsulated potential behaviour for subclassed specializations.”
假设没有IOC
系统内的依赖如同一个图的结构
此时类c
依赖于a
接口的实例和b
接口的实例 ,但是c
的功能可能并不关心a
和b
具体的实现,它需要的仅仅需要是a
或者b
类型实例即可。这时候就需要手动去 new
出来 a
与b
的具体实现类来给到c
那么这样的设计就是很不合理的。
- 耦合性高,可维护性差
- 违反依赖倒置原则
什么是IOC
IOC 是Inversion of Control
的缩写表示 控制反转
在整个系统中IOC就相当于哆啦A梦的口袋,任何对象可以通过这个口袋中拿到。有了IOC容器之后再看c
对象的依赖,它虽然还是依赖于a
和b
但是情况却不一样了
如图所示,此时的情况相当于c
c的依赖交由IOC容器进行管理,在程序运行时IOC容器主动
的将a
和b
进行注入到c
中。这时候 c由主动创建a和b两个依赖的行为被反转为被动接受IOC容器注入a和b依赖
思考一下?
既然是控制反转那么哪些控制被反转了,由上面介绍可见c的依赖控制由主动变为了被动。是获取以来的过程被反转了 恭喜你得到了和2004年,Martin Fowler一样的结论。
IOC容器有什么有点和有什么缺点
优点 它的优点当然是它出生时解决的痛点
- 依赖解耦,可维护性提高
- 资源集中管理,让资源的可配置和更易管理。
缺点
- 复杂性提高效率变慢(原本注入一个依赖就可以,现在却多了整个IOC容器,所以不适用微小型项目)
IOC职责
如下图所示
IOC的实现
IOC有很多的实现
比如
- JavaEE实现
1. JavaBeans
2. Java ServiceLoader SPI
3. JNDI (Java Naming and Directory Interface) - JavaSE实现
1. EJB
2. Servlet - 其他开源实现
1. Apache Avalon
2. PicoContainer
3. Spring Framewrok
可见IOC并不是Spring独有,Spring的IOC实现也是参考了一些其他框架的,关于SpringIOC的详细信息可以参考一下网址 【Spring官方文档】