简单方法：让你理解什么是依赖注入Dagger2(Dependency Injection简称DI）

No DI :

有DI：

这里是怎样使用了DI：
原本在图1： CoffeMaker(){
this.heater =new ElectircHeater();
this.pump =new Thermosiphon(heater)
}
对ElectircHeater类有依赖
但是在图2 中，不是通过内部new 出的，而是通过外部new 出来，然后“喂“进去的。把这种依赖拿掉

好处如图：代码独立

我可以随时更换加热器的牌子和Pump 牌子，而不会使得代码受影响。

而下面也new 了啊，如何解决，需要Factory Pattern ,但是代码量太大，所以需要

常用的框架：

Dagger2 使用：

外面不需要new 了丢给他，而是用Inject：

Inject是什么鬼

先看一段代码：

class A{
B b = new B(…);
C c = new C();
D d = new D(new E());
F f = new F(…..);
}
上面的代码完全没任何问题，但是总感觉创建对象的这些代码基本都是重复的体力劳动，那何尝不想个办法，把这些重复的体力劳动用一种自动化的、更省力的方法解决掉，这样就可以让开发的效率提高，可以把精力集中在重要的业务上了。

我们可以用注解(Annotation)来标注目标类中所依赖的其他类，同样用注解来标注所依赖的其他类的构造函数，那注解的名字就叫Inject

class A{
@Inject
B b;
}

class B{
@Inject
B(){
}
}
这样我们就可以让目标类中所依赖的其他类与其他类的构造函数之间有了一种无形的联系。但是要想使它们之间产生直接的关系，还得需要一个桥梁来把它们之间连接起来。那这个桥梁就是Component了。

重点内容
为啥又造出个Module？？？？？
项目中使用到了第三方的类库，第三方类库又不能修改，所以根本不可能把Inject注解加入这些类中，这时我们的Inject就失效了。
解决：封装第三方类库的代码，并放入Module中，像下面的例子：

@Module
public class ModuleClass{ 
      //A是第三方类库中的一个类
      A provideA(){
           return A();
      }
}

，Module其实是一个简单工厂模式，Module里面的方法基本都是创建类实例的方法。
接下来问题来了，因为Component是注入器（Injector），我们怎么能让Component与Module有联系呢？

*

Component与Module的联系*

Component是注入器，它一端连接目标类，另一端连接目标类依赖实例，它把目标类依赖实例注入到目标类中。
上文中的Module是一个提供类实例的类，所以Module应该是属于Component的实例端的（连接各种目标类依赖实例的端），Component的新职责就是管好Module，Component中的modules属性可以把Module加入Component，modules可以加入多个Module。

但是注入需要提供者，提供者角色就是Module,提供我们所需要的物件：heater pump。
我们需要Pump 和heater,从哪里来？就是Module 给我们。
**

怎么给？Provider注解

**
Provider注解：把Module中的各种创建类的实例方法与目标类中的用Inject注解标注的依赖产生关联。

Module中的创建类实例方法用Provides进行标注，Component在搜索到目标类中用Inject注解标注的属性后，Component就会去Module中去查找用Provides标注的对应的创建类实例方法，这样就可以解决第三方类库用dagger2实现依赖注入了。

这时，Dagger2 会把这个物件的Map画出来，它会知道Pump need heater。当产生一个Pump时，会提供一个heater给它。

有了需要者，和提供者，则两者建立联系则要用Component：
Component现在是一个注入器，就像注射器一样，Component会把目标类依赖的实例注入到目标类中，来初始化目标类中的依赖。

语法：用到一个DripCoffeModule,告诉CoffeeMaker 说：我要用这个DripCoffeModule去产生一个CoffeeMaker即 getCoffeMaker()
然后Dagger会在背后确实这个物件间关系，并帮我们产生一个CoffeeMaker
如图：

总之，3者关系：