浅谈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那么这样的设计就是很不合理的。

1. 耦合性高，可维护性差
2. 违反依赖倒置原则

什么是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容器有什么有点和有什么缺点

优点 它的优点当然是它出生时解决的痛点

1. 依赖解耦，可维护性提高
2. 资源集中管理，让资源的可配置和更易管理。

缺点

1. 复杂性提高效率变慢（原本注入一个依赖就可以，现在却多了整个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官方文档】