You need to tell the Dagger2 how to create your dependency instances of what each one depends on. Dagger2 can't figure everything else, it's not magic ,it can't know the constructor arguments.
Dagger2需要你告诉他如何去创建一个对象，并且如何获取对象所需要的的依赖。Dagger2并不是什么神秘的技术，他就是负责创建对象而已。
好，理清了Dagger2的作用后让我们开始从Application入手吧。
创建Dagger graph
创建这个Dagger graph的作用是生成GitHubService和Picasso对象。所以他们内部依赖的对象OKHttp、Timber、Gson等也会一并被创建。把需要创建的对象大致分成两类，网络相关的Retrofit和图片加载相关的Picasso。这两类又会有公共的部分，比如OKHttp。那么如何创建Dagger graph呢？
1.创建Component
Component是一个public的接口，需要向外暴露获取GithubService和Picasso实例的方法。其余GithubService和Picasso所需要依赖的对象比如OKHttp等应该被隐藏，防止这些类散落到代码中（flying off into the sunset）。让我们创建一个Component，GithubApplicationComponet：
需要注意到的时，要在这个interface上加@Component的注解，这样Dagger2才能知道这是一个Component。这里面两个方法就告诉了graph，这个Component的作用就是提供Picasso和GithubService。当编译这个项目的时候，Dagger就会自动生成一个GithubApplicationComponet的子类，用于提供Picasso和GithubService。但是这些类是从哪里产生的呢？Dagger并不能凭空产生这些类。这里就需要用Module来告诉Component如何得到这些类。
2.创建Module
首先想想创建Picasso和GithubService需要哪些东西呢？上面提到的OKHttp、Timber、Gson还有Context等。这些都需要通过Module来提供。还有GithubService和Picasso本身也要通过Module提供。
首先先编写提供GithubService的Module。代码如下：
和上面Component一样，你要加上
@Module Dagger才知道这是一个Module，这是给Component提供类的。那提供了GithubService就行了吗？不行的，你还要告诉Dagger从哪里获取GithubService，说白了，到哪个Module去获取GithubService这个类。如图：
注意哈，在
@Component后面加了(modules = {GithubServiceModule.class})，这样Component就知道从GithubServiceModule这个Module里能获得GithubServiceModule。至于怎么知道的？当然是根据类型判断呀。你看GithubServiceModule就一个方法返回GithubService，不用它用谁啊。那要是非得抬杠，我又添加一个方法，也是返回GithubService类型的呢？先别着急嘛，凡事都是慢慢来，Dagger准备好方法来应对这样的问题了。让我们先假装刚刚没有发生那个抬杠。
那GithubServiceModule中的githubService()方法如何返回GithubService呢？
对，直接把Application中创建GithubService的代码考过来。但是好像缺
gitHubRetrofit怎么办呢？new一个不就解决了嘛！
卧槽，好像又缺OKHttp和Gson呀。怎么办？还new一个？骚年，此情此景你不觉得熟悉吗？不熟悉？刚才在Application里面不就是这么干的吗？连环new下去，又是一段噩梦代码呀～所以一定不是这么干的！不能new那我就只能通过
githubService(Retrofit retrofit)传一个Retrofit进来了。等等，此情此景好像又在哪里见过！这不就是第一篇文章说的依赖注入Picasso嘛！既然是依赖注入那就统统交给Dagger去解决吧。见代码：
可以看到
gson和retrofit()方法分别返回所需的Retrofit和Gson。但是问题又来了OKHttp是怎么解决的呀？别的Module提供的。是的，Module也能从其他Module中获取对象。@Module后面(includes = NetworkModule.class)了吗？就是从这里获取的OKHttp。至于怎么获取的，和这个GithubServiceModule大同小异。至于为什么要放到不同的Module中，当然是为了更加合理划分Module（卧槽，感觉像是废话。。。）仿佛看见
@Provides在对我笑啊！这又是个什么鬼？其实Module中不是所有的方法都是依赖所需要的类的，那么Dagger就没有必要给这些方法做特殊的处理，也就没有必要加上@Provides注解了（比如这里加上一个根据Debug环境提供不同BaseUrl的方法，其他地方也不会用到BaseUrl，那么这个提供BaseUrl的方法就没有必要加@Provides）。换句话说，如果Module中的方法是提供注入依赖对象的，那么就需要加上@Provides注解。
最后放上获取OKHttp的NetWorkModule的代码：
哎？这里还有个获取Context的Module呢。那么怎么注入Context呢？在ContextModule中new一个？不可能，一定是有特殊的技巧的！具体怎么办，我们下回见！
相关文章：
从实例出发理解Dagger2（一）
从实例出发理解Dagger2（二）
从实例出发理解Dagger2（三）
从实例出发理解Dagger2（四）
从实例出发理解Dagger2（五）
从实例出发理解Dagger2（六）
从实例出发理解Dagger2（七）
参考资料：https://www.youtube.com/watch?v=qxm-1eUMt_c&list=PLuR1PJnGR-Ih-HXnGSpnqjdhdvqcwhfFU&index=2
