Dependency Inversion principle Content Intent 1 2 Definition 3 4 5 Implementation wwwseavuscom Benefits Implications 6 Conclusion 01 Intent wwwseavuscom Dependency Inversion Principle represents the last D of the five SOLID principles of OOP ID: 770796
Download Presentation The PPT/PDF document "Dependency Inversion principle" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Dependency Inversion principle
Content Intent 1 2 Definition 3 4 5 Implementation www.seavus.com Benefits Implications 6 Conclusion
01 Intent www.seavus.com
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. www.seavus.com Intent
02 Definition www.seavus.com
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. www.seavus.com Definition
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. www.seavus.com
03 Implementations www.seavus.com
www.seavus.com 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.
www.seavus.com 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.
04 Benefits www.seavus.com
www.seavus.com Benefits Decoupling Clean code Easier testing Reusibility
05 Implications www.seavus.com
www.seavus.com 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.
06 Conclusion www.seavus.com
www.seavus.com 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.
Thank you for your attention Copyright: © 2019 Seavus . All rights reserved. | www.seavus.com | info@seavus.com | sales@seavus.com