2 things, how do we know what toilet object the human has golden or porta potty I it only had an interface? And, does this mean all objects like the human object have to know what their objects, the golden toilet, abstract to?
This one is technically A Dependency "Injection" Focused Lesson. ruclips.net/video/tW6UHD81SG0/видео.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.
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(); }
@@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
This is the SHIT!!!
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.
The fact that I was watching this while at the toilet totally enhanced the learning experience.
Thanks so much for a great video!
2 things, how do we know what toilet object the human has golden or porta potty I it only had an interface? And, does this mean all objects like the human object have to know what their objects, the golden toilet, abstract to?
I'm a bit late to the party but this has refreshed my knowledge ready for my interview! Thank you!
Best of luck!
This one is technically A Dependency "Injection" Focused Lesson.
ruclips.net/video/tW6UHD81SG0/видео.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.
Cool example Thank you @CleanCodeStudio!
Glad you like it!
How do you know if the human has the golden toilet or portapotty if it only implements an interface of toilet?
thanks
Welcome
??? but methods dont depend on classes so i dont really get the problem it tries to solve
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();
}
@@CleanCodeStudio oh watched it again n now i get it
@@JoshuaKisb Glad to hear it clicked :) Do you mind sharing what your sticking point was and what clicked?
@@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