使用Dagger 2 依赖注入

依赖注入相关概念

单向，表示一个类依赖于另一个类的定义，其中一个类的变化将影响另外一个类，是一种“use a”关系
如果A依赖于B，则B表现为A的局部变量，方法参数，静态方法调用等

public class Person {      public void doSomething(){          Card card = new Card();//局部变量          ....      }  }

public class Person {      public void doSomething(Card card){//方法参数          ....      }  }  

public class Person {      public void doSomething(){          int id = Card.getId();//静态方法调用          ...      }  }  

控制反转（IOC）和依赖注入（DI）的区别

IOC inversion of control 控制反转

DI Dependency Injection 依赖注入

要理解这两个概念，首先要搞清楚以下几个问题：

• 参与者都有谁？
• 依赖：谁依赖于谁？为什么需要依赖？
• 注入：谁注入于谁？到底注入什么？
• 控制反转：谁控制谁？控制什么？为何叫反转（有反转就应该有正转了）？
• 依赖注入和控制反转是同一概念吗？
  （1）参与者都有谁：
  一般有三方参与者，一个是某个对象；一个是IoC/DI的容器；另一个是某个对象的外部资源。
  又要名词解释一下，某个对象指的就是任意的、普通的Java对象; IoC/DI的容器简单点说就是指用来实现IoC/DI功能的一个框架程序；对象的外部资源指的就是对象需要的，但是是从对象外部获取的，都统称资源，比如：对象需要的其它对象、或者是对象需要的文件资源等等。
  （2）谁依赖于谁：
  当然是某个对象依赖于IoC/DI的容器
  （3）为什么需要依赖：
  对象需要IoC/DI的容器来提供对象需要的外部资源
  （4）谁注入于谁：
  很明显是IoC/DI的容器 注入 某个对象
  （5）到底注入什么：
  就是注入某个对象所需要的外部资源
  （6）谁控制谁：
  当然是IoC/DI的容器来控制对象了
  （7）控制什么：
  主要是控制对象实例的创建
  （8）为何叫反转：
  反转是相对于正向而言的，那么什么算是正向的呢？考虑一下常规情况下的应用程序，如果要在A里面使用C，你会怎么做呢？当然是直接去创建C的对象，也就是说，是在A类中主动去获取所需要的外部资源C，这种情况被称为正向的。那么什么是反向呢？就是A类不再主动去获取C，而是被动等待，等待IoC/DI的容器获取一个C的实例，然后反向的注入到A类中。

用图例来说明一下，先看没有IoC/DI的时候，常规的A类使用C类的示意图，如图7所示：

当有了IoC/DI的容器后，A类不再主动去创建C了，如图8所示：

而是被动等待，等待IoC/DI的容器获取一个C的实例，然后反向的注入到A类中，如图9所示：

（9）依赖注入和控制反转是同一概念吗？

    根据上面的讲述，应该能看出来，依赖注入和控制反转是对同一件事情的不同描述，从某个方面讲，就是它们描述的角度不同。依赖注入是从应用程序的角度在描述，可以把依赖注入描述完整点：应用程序依赖容器创建并注入它所需要的外部资源；而控制反转是从容器的角度在描述，描述完整点：容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。

（10）小结一下：

    其实IoC/DI对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC/DI容器来创建并注入它所需要的资源了。    这么小小的一个改变其实是编程思想的一个大进步，这样就有效的分离了对象和它所需要的外部资源，  使得它们松散耦合，有利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活

Dagger 2 依赖注入

1. 依赖 如果在 Class A 中，有 Class B 的实例，则称 Class A 对 Class B 有一个依赖。例如下面类 Human 中用到一个 Father 对象，我们就说类 Human 对类 Father 有一个依赖。

public class Human {    ...    Father father;    ...    public Human() {        father = new Father();    }}

仔细看这段代码我们会发现存在一些问题：
(1). 如果现在要改变 father 生成方式，如需要用new Father(String name)初始化 father，需要修改 Human 代码；
(2). 如果想测试不同 Father 对象对 Human 的影响很困难，因为 father 的初始化被写死在了 Human 的构造函数中；
(3). 如果new Father()过程非常缓慢，单测时我们希望用已经初始化好的 father 对象 Mock 掉这个过程也很困难。

2. 依赖注入 上面将依赖在构造函数中直接初始化是一种 Hard init 方式，弊端在于两个类不够独立，不方便测试。我们还有另外一种 Init 方式，如下：

public class Human {    ...    Father father;    ...    public Human(Father father) {        this.father = father;    }}

上面代码中，我们将 father 对象作为构造函数的一个参数传入。在调用 Human 的构造方法之前外部就已经初始化好了 Father 对象。像这种非自己主动初始化依赖，而通过外部来传入依赖的方式，我们就称为依赖注入。
现在我们发现上面 1 中存在的两个问题都很好解决了，简单的说依赖注入主要有两个好处：
(1). 解耦，将依赖之间解耦。
(2). 因为已经解耦，所以方便做单元测试，尤其是 Mock 测试。

3. Java 中的依赖注入

依赖注入的实现有多种途径，而在 Java 中，使用注解是最常用的。通过在字段的声明前添加 @Inject 注解进行标记，来实现依赖对象的自动注入。

public class Human {    ...    @Inject Father father;    ...    public Human() {    }}

上面这段代码看起来很神奇：只是增加了一个注解，Father 对象就能自动注入了？这个注入过程是怎么完成的？

实质上，如果你只是写了一个 @Inject 注解，Father 并不会被自动注入。你还需要使用一个依赖注入框架，并进行简单的配置。现在 Java 语言中较流行的依赖注入框架有 Google Guice、Spring 等，而在 Android 上比较流行的有 RoboGuice、Dagger 等。其中 Dagger 是我现在正在项目中使用的。如果感兴趣，你可以到 Dagger 实现原理解析 了解更多依赖注入和 Dagger 实现原理相关信息。

最后参考:
uml类图(Class Diagram)中类与类之间的关系
控制反转（IOC）和依赖注入（DI）的区别
使用Dagger 2进行依赖注入