依赖注入Dagger2

帮助博客简书：http://www.jianshu.com/p/cd2c1c9f68d4
：http://android.jobbole.com/82386/

依赖注入的基本概念：
编写代码时我们常常会发现有一些类是依赖于其它类的。所以类A可能需要一个类B的引用或对象。为了理解得更清晰些，我们来看看这个需要使用 Engine 类的 Car 类例子。

public class Car {  

    private Engine engine;

    public Car() {
        engine = new PetrolEngine();
    }
}

这个代码运行正常，但缺点是 Car 和 Engine 之间高度耦合。

Car 类自己创建新的 Engine 对象，则它必须准确知道 Engine 的实现方法，在这个例子中就需要 PetrolEngine 。

我们做些小的改进减少耦合度，来看看创建 Car 类的不同方法吧。

public class Car {   

    private Engine engine;

    public Car(Engine engine) {
        this.engine = engine;
    }
}

这里，我们通过Car 的构造函数，向Car 传递了一个Engine 对象。

这意味着两个对象之间的耦合变低了。

Car类不需要知道 Engine 的具体实现，只要继承了原始 Engine 类，任何类型 Engine 都符合要求。

在这个例子中，通过 Car 类的构造函数传递，或者说是注入了依赖。其实我们已经完成了一种称为构造注入的注入方法，当然，我们也可以通过方法注入或是借助 DI 框架直接执行变量注入。

其实，DI仅仅如此。它最基本的用法就是向类中传递一个依赖，而不是直接在类中实例化。
如果依赖注入那么简单，我们为何需要框架呢？

现在我们理解了DI ，就直接在代码中使用它吧。

我们可以简单地通过一个构造器或是调用方法传递需要的依赖。这种做法对于简单的依赖来说是可行的，但是你很快会发现操作复杂依赖时会变得一团糟。

回到那个有 Engine 依赖的 Car 的例子，想象一下，要是 engine 也设置了依赖，它由曲轴、活塞、机组、头部组成。

如果我们遵循 DI 原理，就需要向 Engine 传递依赖。这情况还不是很糟，我们只需要先创建个对象，然后传递到 Engine 中，最后再传递到 Car 中。

接下来我们举个稍微复杂的例子。

想象一下，如果我们尝试着为 engine 每个部分都创建类，可以预料到最终将会得到许许多多类，有着复杂的树状结构的依赖。

例子的简化依赖关系图。必须首先创建叶子结点上的依赖然后再传递给依赖于它们的对象。所有的对象必须依次创建。

我们必须仔细地按照正确顺序创建对象才能创建好依赖，从叶子结点依赖开始，依次传递到每个父节点依赖，以此类推，直到传递到最高点或是根节点依赖。

事情开始变得复杂了，如果我们还使用工厂方法和生成器来创建类，仅仅是为了传递依赖就要编写相当多复杂的代码，这种代码通常是我们想要避免编写和维护，称为样板文件代码（boilerplate code ）。

从这个例子可以看出，我们自己实现的 DI 会导致出现很多样板文件代码。依赖越复杂，你要编写的样板文件代码就越多。DI 很早就流行了，很早就出现了这些问题，因此也就诞生了解决使用 DI 问题的框架。

通过框架可以很轻松地配置依赖，在某些情况下，还能为了创建对象生成工厂和生成器类，从而直接创建易于控制的复杂依赖。
依赖注入是什么？
目标类：就是需要进行依赖初始化的类。
依赖注入就是目标类中所依赖的其他的类的初始化过程，不需要手动的创建，而是通过技术手段把其他的类已经初始化的实例自动注入到目标类中。

在哪里应用到？
Dagger2：