IoC的基本概念
IoC（Inversion of Control），意为“控制反转”，也叫依赖注入（Dependency Injection），也有人认为依赖注入是控制反转的一种方式。IoC的本质是引入代理者以减少依赖关系。下面通过引入实例以比较IoC的好处
假设存在一个普通的业务场景，获取服务提供者发送的消息并加以处理
以下是上功能实现的类文件
```
public class OurInfoProvider
{
private IOurInfoListener infoListener;
private IOurPersister infoPersister;
public void getAndPersisterInfo()
{
}
}
```
依赖类需要初始化，这是最直接的处理方式，我们主动的创建相关类实例，在OurInfoProvider类中形成了对aInfoListener、aInfoPersister的直接依赖
```
public OurInfoProvider
{
infoListener = new AInfoListener();
infoPersister = new AInfoPersister();
}
```
但是对于OurInfoProvider的业务处理过程，其并不关心依赖对象的实例化过程，只需要订阅或引入它们的实例即可，相关的实例化过程并不应该由OurInfoProvider来实现，对于OurInfoProvider而言，这不是它的职责范围内
基于以上共识，OurInfoProvider只需要引入依赖对象的实例。而依赖对象的实例化过程无法忽略，由其他对象负责；同时OurInfoProvider的引用依赖对象需要来自于一个容器，这就是IoC
依赖注入的方式，构造方法注入、setter方法注入、接口注入，其中接口注入的方式由于侵入性已较少使用；构造方法注入，对象初始化后即可使用，但是构造方法无法被继承、无法设置默认值；而setter方法注入的特点与构造方法相对
构造方法注入：
```
public OurInfoProvider(IOurInfoListener infoListener, IOurInfoPersister infoPersister)
{
this.infoListener = infoListener;
this.infoPersister = infoPersister;
}
```
常常会看到IoC的好处是解耦，但是却不理解这在实际上到底由什么好，下面举例说明
假如增加一个BInfo的信息源以提供OurInfoProvider处理，当我们以直接创建依赖对象时，在OurInfoProvider内确定了接口的实现对象，不能复用以满足BInfo的对象。但是假如我们以构造方法注入，构造方法参数确定接口的实现对象即可。本质上是对初始化的控制权的转移，使得OurInfoProvider不负责可变之处，保持通用性即可
```
OurInfoProvider aOurInfoProvider = new OurInfoProvider(new AInfoListener(), new AInfoPersister());
OurInfoProvider bOurInfoProvider = new OurInfoProvider(new BInfoListener(), new BInfoPersister());
```
通过构造方法注入使得OurInfoProvider不必修改构造方法
IoC使得OurInfoProvider不关心引入依赖对象的初始化过程，也就是其初始化过程对OurInfoProvider是非侵入式、分离的，可以添加钩子等各种处理过程，而OurInfoProvider无感知。例如对引入依赖对象的Mock，但不影响OurInfoProvider的任何逻辑，而这也正符合IoC的意义
来源：https://www.cnblogs.com/elinlinlinlog/p/11060750.html