Inversion of Control The natural evolution of the structured and imperative programming and the usage of reusable frameworks. The execution point where you software takes the control is not defined by your software.
Dependency Inversion One of the most important S.O.L.I.D principles. Depend on abstractions, forget about implementation details. Provide implementation details depending on abstractions can be tedious.
Dependency Injection Software Design Pattern used to facilitate the usage of Dependency Inversion. Provides dependencies given some previous configuration where abstractions are linked with concretions.
Why? The usage of IoC, Dependency Inversion and Dependency Injection provides give us the following benefits: • Testability. • Decoupling. • Modularity.
Dependency Injection Example The presenter inside this fragment has to be instantiated with all the dependency tree. Without a dependency injector this can be tedious.
What can I do? • Do not link the class to the runtime lifecycle or frameworks. • Improve testability. • Decouple your code and improve our software design. • Detect code smells related to class dependencies and SRP violations. • Change the implementation details in build time. • Extract implementation details out of the business logic.
What can I do? Decouple your code and improve our software design. Using a Dependency Injector combined with the correct usage of Dependency Inversion we can easily develop the same feature at the same time in different teams and layers.
What can I do? Extract implementation details out of the business logic. Develop software being agnostic of the Framework or the Runtime used. Implementation details are provided using the dependency injector and your business logic does not depend on it.
What can I do? The dependency container provide us different configurations to provide dependencies: • Singletons. • Lazy Initialization. • Provided dependencies. • Named dependencies. • Override dependencies already configured. • Custom qualifiers.
Scoped Graphs Dependencies provided by the Dependency Container or Object Graph inside the Application class are linked to the Application lifecycle. We need more than one graph to improve the Dependency Injector usage and performance. At the same time, some dependencies are needed just when some components like Activities or Custom Views are initialized.
Dagger 2 • Configuration based on components not in graphs. • Generated code is now something you can read. • Reflection free. • 13 % faster. • Full graph validated in build time.