全面理解控制反转和依赖注入

一、控制反转和依赖注入之间的关系

控制反转（Inversion Of Control, IOC）是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency Injection, DI）, 还有一种叫”依赖查找”（Dependency Lookup）。通过控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用传递给它。也可以说，依赖被注入到对象中。

通过上面的解释大家能看的出来，控制反转是一种设计原则而依赖注入是用来实现控制反转的一种设计方式。

二、什么是依赖注入

首先明确一点，依赖注入 是一种设计方式，而不是一种技术。那么什么样的方式才是依赖注入的设计方式那？

说白了就是：

不是我自身的，但却是我需要的，都是我所依赖的。一切需要外部提供的，都是需要依赖注入的。

下面用代码来解释一下依赖注入的设计方式。
假如有一个船(C)类，一个桨(J) 类。

class C{
  J j = new J() ;
}

如果船要干什么事，肯定需要浆的参与。所以是十分 “依赖”浆；
出了需求需要重构：这时候我们需要控制浆的长度为10在构造方法中。我们需要这么写；

class C{
  J j = new J(10) ;
}

一个特性需要修改浆构造方法，又需要修改船其中的new J()方法。这时候就设计者就思考，为什么我们加入一个特性需要更改两个类中代码（这也就是耦合度高）！所以我们要解耦要依赖注入；

常用解耦方式：

构造方法注入如下：
我重构代码的时候在也不用看哪里的浆还是短的了！因为船构造方法依赖了浆。任你浆怎么设计，我用的时候传一个浆进来即可。（下层依赖上层，用的时候传入，而不是针对下层去修改）

class C{
  J j 
  public c（J j）{
     this.j = j;
  };
}

那么现在应该怎么去初始化浆那？
目前主流的实现方式有两种。

1、工厂模式注入
工厂模式 Human 人去注入; 工厂类如下

Class Human {
   J j =new J（）;
   J getJ（）{
      return j ;
   }
}

此时如下：不管你怎么改浆，改成100米与船都无关，他只要依赖Human,
一千个船修改浆需求我只修改Human类中方法便可。（核心业务逻辑需要依赖的类实例化交给第三方类来实现注入。）

Class C {
  J j ;
  Human h = new Human；
  j=Human.getJ();
}

2、框架注入（Dagger2）
篇幅较长，将单独一篇。

三、为什么要有控制反转和依赖注入

为什么要有依赖注入（一种设计代码模式）？
因为我们要控制反转（设计代码的思路）。
为什么控制反转？
因为我们软件设计需要符合软件设计原则依赖倒置（设计代码原则），单一职责原则。
说通俗点就是咱们要解耦啊。
MVP模式就是解耦比较全面的设计模式模型，