对IOC的理解

对IOC和DI概念的基本认识

1、理解IOC(控制反转)

(1)背景

我们知道在面向对象设计的软件系统中，它的底层都是由N个对象构成的，各个对象之间相互合作，互相依赖，最终实现系统地业务逻辑。有依赖就有耦合，伴随着工业级应用的规模越来越庞大，对象之间的依赖关系也越来越复杂，经常会出现对象之间的多重依赖性关系，因此，架构师和设计师对于系统的分析和设计，将面临更大的挑战。对象之间耦合度过高的系统，必然会出现牵一发而动全身的情形。为了解决对象之间的耦合度过高的问题，软件专家Michael Mattson 1996年提出了IOC理论。

IOC是Inversion of control的缩写,翻译为控制反转，为spring两大核心之一。要理解控制反转，就需要从控制入手。

(2)什么是控制

先看一张图

 A,B,C,D四个对象都存在依赖关系，这些对象相互啮合在一起，共同完成一项工作。其中A对象可以通过new()方法直接获取依赖对象B，并且可以操作B中的属性和方法，在这整个过程，都是A主动创建对象并使用的，也就是说是A在主动控制这个过程，控制权是在A手中的。

但是这样做弊端是非常明显的，他们之间的相互依赖使得对象之间的耦合度非常的高，一旦其中的某一个齿轮出现问题，整个系统都会停止运转。

(3)什么是控制反转

再看一张图

 在这张图中引入了一个第三方的IOC容器，这个IOC容器就是降低耦合度的关键所在。

那么这怎么就叫控制反转了呢?

首先，由于引入了IOC容器，现在A要用到B不是通过直接在A中new对象了，而是让IOC容器给你一个B实例。首先B会先注册进IOC容器中，IOC容器拿到这个bean过后再通过依赖注入(DI)的方式注入进A中，这整个过程不再是A主动创建B对象了，而是A在被动接受IOC容器给A注入的B，这个B实例是IOC容器通过反射创建的，控制权移交到了IOC容器那里。也就是说，对象A获得依赖对象B的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。

(4)怎么解的耦

通过上面的说明，我们不难发现，引入了IOC容器之后，A,B,C,D四个对象之间没有了直接依赖关系，他们之间的传动全部依靠第三方IOC容器了

现在把IOC容器拿开来再看整个系统

 这个时候，A,B,C,D四个对象之间已经没有了直接耦合关系，我们在实现A的时候已经不在需要考虑B,C,D了，我们只需要伸手向IOC容器拿就行了。这就实现了解藕。

2.IOC也叫依赖注入(DI)

通过上面的例子我们知道，获得对象的过程发生了控制反转(IOC)，获得对象的过程是由容器依赖注入(DI)的，所以，IOC和DI其实是在两个不同的角度描述同一件事物。而IOC的整个思想其实也就是通过引入IOC容器，利用依赖注入的方式，实现对象之间的解藕。