Dagger2 difference between modules and dependent

Question

I don’t understand the difference between telling a component what its modules are and telling the component what its dependent components are.

For example:

@Module public class ModuleA { @Provides DependencyA providesDependencyA() { return new DependencyA(); } } @Module public class ModuleB { @Provides DependencyB providesDependencyB() { return new DependencyB(); } } @Component (modules = {ModuleA.class}) public interface ComponentA { DependencyA getDependencyA(); } 

what's the difference between this:

 @Component (modules = {ModuleA.class, ModuleB.class}) public interface ComponentB { DependencyB getDependencyB(); } 

So what:

 @Component (dependencies = {ComponentA.class}, modules = {ModuleB.class}) public interface ComponentB { DependencyB getDependencyB(); } 

Answer 1

For your simple case, they behave about the same; if you want, you can think of handling Dagger component dependencies as if it installed an automatically generated module that wraps each provision method (zero-arg factory method) depending on the @Provides method that delegates the instance you pass into. In any case, Dagger will generate an implementation of the Factory / Provider class that delegates the module / dependency method that you consume.

However, there are some big differences, including the following:

• Modules can take other arbitrary parameters of each method, obtained from the graph of the object. Collateral methods in component dependencies must be zero-arg. This is the most significant difference: Component dependencies are pure external factories, not full members of the object graph.
• Methods for providing the module must be declared using @Provides for the dagger in order to use them, which also allows the use of inexperienced methods with a null argument. Component dependencies treat each zero-arg method as a potential provider.
• Modules must be annotated using @Module . Component dependencies can be arbitrary types (not necessarily just @Component -independent instances), and you can pass any implementation regardless of whether it generates a Dagger.
• Modules and module methods will check their areas; they must be compatible with the component scope. Component dependencies are not checked by region.
• Modules can be abstract classes or interfaces, allowing you to use @Binds to express declarative bindings in your graph. Component dependencies are instances by definition and do not have access to anything in your object graph.
• Of course, modules can declare the subcomponents that they use, or their dependencies on other modules. Component dependencies cannot do anything; it's just external factories.
• Instant modules do not have to be supplied in the component builder if they have public methods with a null argument. Component dependencies must be provided , even if you must provide a specific type that a dagger can create.

In short, consider modules as a configuration of your graphs and component dependencies as external from outside your graph. In addition to the narrow overlap that you described above, it should be clear enough what role you want for any given class.