Dependency Inversion Principle (PHP SOLID Design Principles)

The #DependencyInversion Principle is most notable for being the D in the infamous #SOLID Design Principles.
The dependency inversion principle states that higher level modules should not depend on low level modules ~ both higher and lower level modules should depend on abstractions. Abstractions should not depend on details.
Details should depend upon abstractions.
Dependency Inversion is one of the most powerful design patterns out there due to it allowing us to invert our dependency tree, but out of all of the SOLID Principles ~ Dependency Inversions is probably the most complicated...at first glance.
1. Higher level modules: Accept Abstraction As Parameter Or Argument
2. Lower level modules: Implement Abstraction's behavior
3. Higher level modules depend on abstract by accepting them as arguments while lower level modules depend on abstractions by implementing the required behavior demanded by the interface.
The lower level module is responsible for implementing the required behavior.
Dependency Inversion. #ObjectOrientedDesignPatterns
~~~~~~~~~~~~~~~~~~~~~~
Clean Code Studio ~ Simplify!
Clean Code Clean Life
cleancode.studio
cleancode.stud...

[@AmreshTripathi]

This is the SHIT!!!

[@CleanCodeStudio]

This comment is deserving of more than zero likes. I'm liking this comment, then I'm highlighting this comment and pinning it to the top.

[@CleanCodeStudio]

This one is technically A Dependency "Injection" Focused Lesson.
th-cam.com/video/tW6UHD81SG0/w-d-xo.html
That being said, we also cover Dependency "Inversion" in a more visualized way in this lesson. I'd recommend watching this lesson, then if Dependency Inversion doesn't click all the way move on over and check out this lesson on "Dependency Injection". Mid way through, we dive into how we can use Dependency "Injection" to implement Dependency "Inversion". We break down higher level modules and lower level modules and a very visually understanding way.

[@joshualim5587]

thanks

[@CleanCodeStudio]

Welcome

[@lizamali1619]

Cool example Thank you @CleanCodeStudio!

[@CleanCodeStudio]

Glad you like it!

[@thisdotadam]

I'm a bit late to the party but this has refreshed my knowledge ready for my interview! Thank you!

[@CleanCodeStudio]

Best of luck!

[@dawid_dahl]

The fact that I was watching this while at the toilet totally enhanced the learning experience.
Thanks so much for a great video!

[@JoshuaKisb]

??? but methods dont depend on classes so i dont really get the problem it tries to solve

[@CleanCodeStudio]

Methods, or functions, can depend on class behavior.
Image your phone and all of the apps you are able to use on your phone.
What if Google or Apple developers had to take into account how to run or execute all of the apps your phone could download? That would be insanity and the apple and android platforms wouldn't be nearly as cool as they are.
Your phone instead can
1. Install Apps
2. Run Apps
Your phone does NOT know HOW the apps you install do what they do. Your phone just knows the Apps CAN do something and that it needs to be able to install and run them.
Once the apps are running, it is up to the creator of the App to determine HOW it does whatever it needs to do.
This is an example of why interfaces or contracts are so stinking valuable.
You know that a class CAN do something, you don't know HOW it does it.
Your phone knows an App CAN do something, it doesn't know exactly HOW it does that something.
Your phone just knows it needs to be able to install the App and run the app so it can handle whatever it is the App handles.
Code Example:
interface PhoneApp
{
public function install();
public function run();
}
// implement the interface on the FlashLightApp interface
class FlashLightApp implements PhoneApp
{
public function install() {
// require access to phone light
// require access to phone battery life
}
public function run() {
// pull up light app user interface
// pull in user interface images
// When light button is turned on, turn phone light on
// When light button is turned off, turn phone light off
}
}
// implement the phone application on the MapApp class
class MapApp implements PhoneApp
{
public function install() {
// require access to gps
// require access to phone battery life
}
public function run() {
// pull up gps location on phone
// pull up gps map user interface
// calculate distance between user current location and location xyz...
// etc...
}
}
// Accept the interface instead of a specific class
function runPhoneApplication(PhoneApp $app)
{
// By depending on the PhoneApp interface we can run Any Phone App
// as long as the class implements the PhoneApp Interface.
// We know, because we're accepting the interface that we can execute the
// "run" function on our $app object.
$app->run();
}

[@JoshuaKisb]

@@CleanCodeStudio oh watched it again n now i get it

[@CleanCodeStudio]

@@JoshuaKisb Glad to hear it clicked :) Do you mind sharing what your sticking point was and what clicked?

[@JoshuaKisb]

@@CleanCodeStudio well when i first watched you were saying flush for this toilet depends on sewage plant and bunch of other classes so we change to have it depend on interface,
on reading comment i get that the point is to simply care about whether it can flush and leave it up to the class to take care of its own dependencies.... i think thats what it meant
the sticking point was what happens to dependencies before and after
i got the sense that before they were created by the action using the method and after they move to the class