Dependency Inversion principle

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

01 Intent www.seavus.com

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. www.seavus.com

02 Definition www.seavus.com

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. www.seavus.com

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. www.seavus.com

03 Implementations 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. www.seavus.com

04 Benefits www.seavus.com

Benefits Decoupling Clean code Easier testing Reusibility www.seavus.com

05 Implications 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. www.seavus.com

06 Conclusion 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. www.seavus.com

Thank you for your attention Copyright: © 2019 Seavus. All rights reserved. | www.seavus.com | info@seavus.com | sales@seavus.com