1. Dependency Inversion principle

2. 1 2 3 4 5 6 Content Intent Definition Implementation Benefits
Implications 6
Conclusion

3. 01
Intent

4. Intent
Dependency Inversion Principle represents the last “D” of the five SOLID principles of OOP.
The general idea of this principle is as simple as it is important: High-level modules, which provide complex logic, should be easily reusable and unaffected by changes in low-level modules, which provide utility features. To achieve that, you need to introduce an abstraction that decouples the high-level and low-level modules from each other.

5. 02
Definition

6. Definition Robert C. Martin definition:
A. High-level modules should not depend on low-level modules. Both should depends on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
Depend upon abstraction. Do not depend upon concrete classes.

7. the high-level module depends on the abstraction, and
An important detail of this definition is, that high-level and low- level modules depend on the abstraction. The design principle does not just change the direction of the dependency, as you might have expected when you read its name for the first time. It splits the dependency between the high-level and low-level modules by introducing an abstraction between them. So in the end, you get two dependencies:
the high-level module depends on the abstraction, and
the low-level depends on the same abstraction.

8. 03
Implementations

9. A direct implementation packages the policy classes with service abstracts classes in one library. In this implementation high-level components and low-level components are distributed into separate packages/libraries, where the interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component's library. The implementation of the high-level component's interface by the low level component requires that the low-level component package depend upon the high-level component for compilation, thus inverting the conventional dependency relationship.

10. A more flexible solution extracts the abstract components into an independent set of packages/libraries. The separation of all layers into their own package encourages re-utilization of any layer, providing robustness and mobility.

11. 04
Benefits

12. Benefits Decoupling Clean code Easier testing Reusibility

13. 05
Implications

14. Implications
The presence of interfaces to accomplish the Dependency Inversion Principle (DIP) has other design implications in an object-oriented programing:
All member variables in a class must be interfaces or abstracts.
All concrete class packages must connect only through interface or abstract class packages.
No class should derive from a concrete class.
No method should override an implemented method.
All variable instantiation requires the implementation of a creational pattern such as the factory method or the factory pattern, or the use of a dependency-injection framework.

15. 06
Conclusion

16. Conclusion
The Dependency Inversion Principle is the fifth and final design principle that we discussed in this series. It introduces an interface abstraction between higher-level and lower-level software components to remove the dependencies between them.
This might sound more complex than it is. You only need to consequently apply the Open/Closed and the Liskov Substitution principles to your code base. After you have done that, your classes also comply with the Dependency Inversion Principle. This enables you to change higher-level and lower-level components without affecting any other classes, as long as you don’t change any interface abstractions.
Of course, using this principle implies an increased effort, will result in more classes and interfaces to maintain, in a few words in more complex code, but more flexible. This principle should not be applied blindly for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.

17. Thank you for your attention
Copyright: © 2019 Seavus. All rights reserved. | | |