solid principles part 3
TRANSCRIPT
![Page 1: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/1.jpg)
SOLID Principles - IIIDIP – Dependency Inversion Principle
Maulik Soni
![Page 2: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/2.jpg)
Maulik Soni
Dependency Inversion Principle
High-level modules should not depend on low-level modules Both should depend on abstractions
Abstractions should not depend on details Details should depend on abstractions
![Page 3: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/3.jpg)
Maulik Soni
Dependency Inversion Principle
DIP is at the very heart of framework design
![Page 4: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/4.jpg)
Maulik Soni
How To Spot DIP Violation ?
Direct Instantiation new SomeObject();
Static Methods ServiceLocator.getObject();
![Page 5: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/5.jpg)
Maulik Soni
Is DIP Violated Here ?
![Page 6: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/6.jpg)
Maulik Soni
Resolution
![Page 7: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/7.jpg)
Maulik Soni
Inverted Dependencies
![Page 8: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/8.jpg)
Maulik Soni
Demo
Demo of DIP and Dependency Injection using Unity
![Page 9: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/9.jpg)
Maulik Soni
Summary
Depend on abstractions No variable should hold a reference to a concrete class No class should derive from a concrete class No method should override an implemented method of any of its base classes
Heuristic is typically violated at least once Somebody has to create the instances of the concrete classes No reason to strictly follow this heuristic for classes that are concrete but non-volatile
![Page 10: SOLID Principles Part 3](https://reader036.vdocuments.us/reader036/viewer/2022082906/58f19e2d1a28abdc328b4577/html5/thumbnails/10.jpg)
Maulik Soni
End of Presentation
End of Introduction to SOLID Principles S = Single Responsibility O = Open / Closed L = Liskov Substitution I = Interface Segregation D = Dependency Inversion