这部分会介绍一下DI的主要概念，包括Component,Module,但不涉及和Android有关的具体代码。

目的是在剥离实际开发的情况下先建立Component的概念，因为在DI中这是它的最主要部分，而Component概念在Android开发经验中是不存在的。

开始以下的内容之前请忘记所有我们学过的Android知识。。。

依赖

什么是依赖？

我的理解，依赖是一个对象的存在需要依附另外一个对象，或者说一个对象需要另外一个对象。

我们先在不使用DI的情况下描述一个具体事例，然后再用DI改造我们的代码。

举个例子，我们有个咖啡机(这个例子很多介绍Dagger2的地方都用到)，就像在星巴克看到的那样，一个咖啡机需要一个泵和一个加热器才能工作

class CoffeeMachine {

Pump pumper;

Heater heater;

public static Coffee makeCoffee(){...}

}

interface Pump {

void pump();

}

interface Heater {

void heat();

}

因为Pump和Heater可能有各种不同的实现方式，比如Heater有电子加热，也有蒸汽加热，所以这里以接口声明，Pump我们就用虹吸吧，然后是具体的实现方式

class Thermosiphon implements Pump {

@Override

void pump() {

//impl

}

}

class EletricHeater implements Heater {

@Override

void heat() {

//impl

}

}

OK，现在我们来做咖啡了，在不使用DI的情况下，我们会在Machine中直接实例化对象，

class CoffeeMachine {

Pump pumper;

Heater heater;

public CoffeeMachine() {

this.pumper = new Thermosiphon();

this.heater = new EletricHeater();

}

public static Coffee makeCoffee(){...}

}

咖啡机做咖啡的过程所需要的依赖就如上面的代码描述的一样，我们只要使用 CoffeeMachine.makeCoffee() 就可以做咖啡了。

依赖注入

然后我们引入DI的概念，来说明如何通过DI来解耦。

来看一张对比图

iDI 重构前后对比

左边是在不使用DI的情况下，Machine和Pump和Heater的关系图，右边是使用了DI的情况。

对于左边，假设一种情况，老板某一天觉得得有个咖啡师在煮咖啡才显逼格，导致我们的Heater需要引入一个Cooker作为构造参数，

class EletricHeater implements Heater {

public EletricHeater(Cooker cooker) {

...

}

}

此时发生了问题，我们必须要修改Machine中对它的实例化方法。这不是我们想要的，试想在一个大型项目里，一个类的构造方法发生变动，就需要修改所有有引用到的地方，工作量巨大。

应对这种情况，一般我们会构造一个Factory类来进行实例化，再把实例化后的Heater对象set进Machine，这么做就实现把依赖的类的实例化逻辑放到一个统一的地方，让他们解耦。

class CoffeeMachine {

Pump pumper;

Heater heater;

public CoffeeMachine(Pump pumper, Heater heater) {

this.pumper = pumper;

this.heater = heater;

}

}

void main {

CoffeeMachine machine = new CoffeeMachine(PumpFactory.getInstance().buildPumper(),

HeaterFactory.getInstance().buildHeater());

}

代码类似上面这样，具体Factory的实现比较普通就不细写了。

上面的代码就是粗略的依赖注入了，Machine不知道或者不关心具体实例的生成，它只关心它依赖于这两个类，而heater和pumper的实例都是先在别的地方实例化完了再注入到Machine中的。

虽然用Factory类可以解耦，但是取而代之的是我们还要维护具体的Factory代码，还是有工作量的。

Dagger2帮我们做了Factory代码这部分，所有的模板代码都可以直接在编译期生成，我们只需要维护一份接口代码，用来描述各个类的依赖关系就行。

Component + Module

现在，以上面的场景为例子来说明这两个东西的概念。

Component，中文可以理解为组件，比如聊天组件，数据组件，或者是Presenter。

Module，中文可以理解为模块，是提供功能给Component使用的一种存在。

以CoffeeMachine为例。这里的Component可以定义为咖啡机，而Heater和Pumper可以定义为Module。

下面用代码来描述他们的依赖关系

首先定义Module

@Module

public class HeaterModule {

@Provides

public Heater provideHeater() {

return new EletricHeater();//此时老板还没改需求

}

}

@Module

public class PumperModule {

@Provides

public Heater providePumper() {

return new Thermosiphon();

}

}

然后是Component

@Component {modules = {HeaterModule.class, PumperModule.class}}

public interface MachineComponent {

void inject(CoffeeMachine machine);

}

用这三个类/接口的代码，就描述了他们之间的依赖关系。先不解释这代码的语法含义，接着，在定义好依赖关系后首先来看怎么在代码中使用Dagger2注入对象。

class CoffeeMachine {

@Inject Pump pumper;

@Inject Heater heater;

public CoffeeMachine() {

}

public void makeCoffee() {

mPumper.pump();

mHeater.heat();

}

}

WTF?是的没错只需要用@Inject注解标注需要注入的对象就行了，Dagger2会负责所有的实例化和注入过程。

注意需要注入的对象不能声明为 private，否则Dagger2会没办法注入，因为它不是用反射的方式注入的。

上面就是最简单的Dagger2的使用场景了，这里面忽略了很多细节，只是把重点放在了Component和Module这两个概念上。

通过Dagger2，把原本类和类之间的关系，用Component和Module来描述。Machine类也不再需要关注所依赖的Heater是怎么实例化的了，它只需要知道接口就可以使用。而类和类之间的依赖关系则由Component去解决，这部分依赖关系，可以放到一个独立的package下面去维护。

刚接触的开发者可能会觉得这不是更麻烦了吗，代码量比以前更多了，为什么要这么复杂？当然主要因为这是一个非常简单的例子，假设是在大型的项目上，有几百个类的情况下，各个模块之间的关系在依赖描述下能非常清晰的理解，而且互相之间耦合很低，只需要修改接口文件就可以快速的替换具体的业务逻辑，在这样的场景下用DI是非常划算的。

总结

回到图一，通过DI，现在类和类之间的耦合已经完全分离了。我们也大致了解了DI的概念，和Dagger2对Component和Module的定义。然而真正实现DI的核心代码是Dagger2自动生产的，我们需要看这部分代码，才能真正明白Dagger2的工作原理，还有更深层次的去理解Dagger2的核心高级用法，像@Scope，@SubComponent。对于大型项目来说，@Scope和@SubComponent是绝对需要熟悉的东西。包括原理和高级用法在接下来的几篇里继续描述。