很显然，Context并不能通过new的方式提供，那么就通过构造函数传参的方式提供。详细代码如下：
image.png
可见必要的提供Context的
context()的方法还是有的，而且用@Provides注解。至于这个ContextModule是什么时候被初始化的，通过什么样的方式传入到Dagger里面的，这个我们稍后再讲。
那么通过这种注入方式，也可以提供Picasso。新建一个PicassoModule：
image.png
不难看出使用Dagger2会尽可能少的直接在需要依赖的地方new一个对象，而是通过Dagger去获取一个对象。
那么会不会感到疑惑，Dagger究竟是怎样帮助我们生成所需要的类呢？通过点击下图中的红色方框部分可以看到Dagger为我们生成的代码。
image.png
生成的代码如下：
image.png
image.png
image.png
image.png
可以看到Dagger生成了提供各个类的Provider，在
initialize()中的初始化顺序是按照正确的逻辑顺序生成的，虽然我们并没有指定它的顺序，这一切都是Dagger自动完成的。为了使用Dagger为我们生成的类，我们就必须创建GithubApplicationComponent的实例。代码如下：
image.png
看到了吗，含有context的Module就是通过这样的方式被初始化，并且传入Dagger的。通过创建的component就可以获取需要的githubService和picasso啦。但是大家有没有发现一个问题，这里面每个Module都需要new一个传进去，假如有个50个Module，这工作量也不少啊，而且容易漏。事实上Dagger只需要传入一个ContextModule就行了，其余的Module都会自动帮你生成。就像下面这样：
image.png
如果你会看上面Dagger帮我们生成的代码时，里面
build()方法，你就会发现，Dagger会检查需要的类，如果为空就帮我们生成所需要的类。唯一一个一旦为空就抛出异常的的Module就是ContextModule，因为Dagger并不知道如何创建这个类。
怎么样，再对比刚开始Application中的类，是不是感觉少了很多代码。接下来的文章将会介绍Scope的使用。
相关文章：
从实例出发理解Dagger2（一）
从实例出发理解Dagger2（二）
从实例出发理解Dagger2（三）
从实例出发理解Dagger2（四）
从实例出发理解Dagger2（五）
从实例出发理解Dagger2（六）
从实例出发理解Dagger2（七）
参考资料：https://www.youtube.com/watch?v=gg1zxoVStBM&list=PLuR1PJnGR-Ih-HXnGSpnqjdhdvqcwhfFU&index=3
