Dependency inversion principle
Definition
A. High-level modules should not depend on low-level modules. Both types of modules must depend on abstractions.
B. Abstractions should not depend on details. The details should depend on the abstraction.
The first definition includes the concept of “module”. This is a very important concept without which DIP cannot be understood.
module - a logically interconnected set of functional elements
To avoid misunderstandings, consider the definitions using an example. Let's say we need to get a list of read books and display it to the user. For this we will use the BooksInteractor and BooksRepository classes. We put each of these classes in its module BI and BR, respectively. The BooksInteractor class module depends on the BooksRepository class.
BooksInteractor'y need to get a list of books from BooksRepository. The Interactor does not care at all how the repository receives this data, which means that in this case, BooksInteractor is an abstraction for BooksRepository. According to the second definition, BooksInteractor (abstraction) should NOT depend on BooksRepository (implementation). On the other hand, the repository must know about the BI module. So what happens: the interactor must be inside the repository? No, to invert the dependencies, we just need to cover the BooksRepository with the IBooksRepository interface, and put this interface into the module of the BooksInteractor class. Now let's go back to the 1st definition of DIP and take a look at the diagram.
Look, the higher-level modules (BI module) do not depend on the lower-level modules (BR module). And both modules depend on abstraction (on the IBooksRepository interface). If you've caught the magic of dependency inversion by covering a repository with an interface, you understand the principle of dependency inversion. Congratulations! The hardest part you understand. You can read more about DIP in this article on Habré.
Inversion of Control
We studied the concept of "Dependency Inversion Principle". Now let's move on to another inversion - inversion of control. The concept itself is very broad and in programming it can mean one of three things:
- Inversion of interfaces - delegation of the relationship between modules to an intermediary interface. Where does it apply? For example, in the DIP, which we studied earlier.
- — (, DI/IOC ).
- — , . , , — Android . Activity Fragment, .
Dependency Injection
Dependency injection is a mechanism for passing its dependencies to a class. You always come across this when you need to pass a dependency to another class. There are several ways to inject dependencies: through a constructor (Constructor Injection), through a method (Method Injection), and through a property (Property Injection). Each of these methods is used for its own purposes. But here it is important to understand that Dependency Injection is just passing a dependency to a constructor, method or property.
Considering edge cases
- Could there be DI without IoC and DIP? Yes maybe. We create an instance of a concrete class A and pass it to an object of class B through a constructor, method or property.
- Could there be DIP without IoC? No, DIP is one way to implement Interface Inversion in IoC.
- Can there be DIP without DI? Yes, we can tie the lower modules to the interface. The upper module classes will work with an interface abstraction, but the concrete implementation of the lower module class will be created in the constructor of the upper module.
You can find out the differences between DIP, DI and IoC from other authors here and here .
I would be glad to receive your comments and feedback!