上一期介绍了Dagger是如何应对多个同类型变量的，这一期主要介绍，在对原对象不做任何修改的情况下如何将其注入。
主体代码
现在将ClassA的所有标注全都去掉：
public class ClassA {
private int a;
private int b;
public ClassA(int a, int b) {
this.a = a;
this.b = b;
}
public int getA() {
return a;
}
public int getB() {
return b;
}
}
好了，那么现在Dagger要从哪里知道ClassA的构造函数以及参数呢？
答案是在Module里。现在Dagger自己无法查到ClassA的带@Inject标注的构造器了，于是转而要Module @Provides一个出来，具体如下：
@Module
public class ModuleA {
private int a;
private int b;
public ModuleA(int a, int b) {
this.a = a;
this.b = b;
}
@Provides
@Named("a")
int provideIntA() {
return a;
}
@Provides
@Named("b")
int provideIntB() {
return b;
}
@Provides
ClassA provideClassA(@Named("a") int a, @Named("b") int b) {
return new ClassA(a, b);
}
}
是不是和原来的ClassA的构造器很像？更神奇的一点是，Dagger会自动搜索所需参数，然后在这里找@Provides同类型参数的函数，同样多个同类型的参数可以用@Named来解决。
当然也可以不必这么麻烦，可以在构造ModuleA的时候new一个ClassA出来，到时候返回去。可见Dagger也是很有自由发挥空间的，只要把握几个要点就可以了。
比如说Dagger生成的DaggerComponent其实可以不急于inject，而是需要的时候再inject。常见的就是在App初始化的时候生成一堆之后可能需要的DaggerComponent，然后等哪个地方需要就获取然后再注入。
MainActivity与ClassAComponent并没有什么变化。
生成代码
生成代码没有太多变化，除了ClassA原来的构造器Dagger不知道了，现在用ModuleA_ProvideClassAFactory来代替：
public final class ModuleA_ProvideClassAFactory implements Factory<ClassA> {
private final ModuleA module;
private final Provider<Integer> aProvider;
private final Provider<Integer> bProvider;
public ModuleA_ProvideClassAFactory(
ModuleA module, Provider<Integer> aProvider, Provider<Integer> bProvider) {
assert module != null;
this.module = module;
assert aProvider != null;
this.aProvider = aProvider;
assert bProvider != null;
this.bProvider = bProvider;
}
@Override
public ClassA get() {
return Preconditions.checkNotNull(
module.provideClassA(aProvider.get(), bProvider.get()),
"Cannot return null from a non-@Nullable @Provides method");
}
public static Factory<ClassA> create(
ModuleA module, Provider<Integer> aProvider, Provider<Integer> bProvider) {
return new ModuleA_ProvideClassAFactory(module, aProvider, bProvider);
}
/** Proxies {@link ModuleA#provideClassA(int, int)}. */
public static ClassA proxyProvideClassA(ModuleA instance, int a, int b) {
return instance.provideClassA(a, b);
}
}
生成的代码确实是“一个模子”里出来的。
这里体现出封装的好处了：在无法直接调用构造器的情况下，使用Provider接口封装之后其余代码几乎没有什么区别。
到目前为止，我们看到的只是很简单的依赖关系，那么交叉依赖又如何？例如ClassB需要ClassA与另一个整数a，而ClassA又依赖于a？Dagger是提供了很多方法来解决的，我们拭目以待吧。
