Dependency Inversion Principle Explained - SOLID Design Principles

hello everyone in today's video we're gonna be covering dependency inversion which is a fairly abstract concept to think about so in this video I'm gonna simplify it and give you concrete examples of dependency inversion so you will understand it in depth by the end of this video let's get started now welcome back to web dev simplified my name is Kyle and my job is to simplify the web for you so you can start building your dream project sooner so if that sounds interesting make sure you subscribe to the channel for more videos just like this one now to get started I want to talk about the abstract concept of what the dependency inversion principle is by using a concrete example and right now we have an application that allows users to buy different things from our store so we have some form of store over here on the left hand side which is calling out to the stripe API in order to handle all of the credit card information and user payment processing so what this is saying is our store depends on the stripe API and inside of our code we have exact lines that say like stripe dot make payment or striped check credit card inside of our store code so our store is very coupled to our stripe API it calls it directly and this is a little bit of a problem because what happens if we want to test our code very easily we have to make all of these calls to the stripe API and we don't want to call the stripe API while we're testing also what if we want to switch to PayPal or allow them to pay with PayPal on top of stripe adding that in means we have to change tons and tons of code in our store swap out all that stripe code and put in all of this paypal code so what happens in the dependency inversion principle is that you add in a piece in the middle kind of an interface which contains all of the behavior that we want our API to be able to do so we implement this payment processor and now our store calls the payment processor and says payment processor dot check credit card or payment processor dot make payment whatever it is and this payment processor doesn't depend on anything it's just an API it's just two functions that we could call like check credit card do this do that make payment it doesn't matter what it is but it's just an idea of what we can do and then we have a specific implementation so we have our stripe implementation of our payment processor and now we can just plug our stripe implementation into our store we give our store the stripe implementation and it'll call methods on the payment processor but those payment processor methods will actually be calling this stripe API since it's set up to Gale delegate those methods to stripe and that stripe interface that we created is allowing it to talk with stripe so what this allows us to do is to actually have two different API as we can create a payment processor for PayPal and a payment processor for stripe and they both use the same exact API the same exact underlying functions so our store never has to change unless we change our payment processor which is just an abstract idea of the different types of payments that we can make the idea of this is a lot of times referred to as like the adapter pattern or the facade pattern where you create this wrapper essentially around external dependencies that you have so that way your code depends on the wrapper you created and not the actual implementation of the detail for the dependency you're using and that's the idea of dependency inversion you do not want your high level code for example this store class this store method whatever it is to depend upon the low level implementation of your dependencies we don't want it to depend on how stripe works or how PayPal works we don't depend on this payment processor that wraps those functionalities which is something that we can control and easily make stripe and PayPal look exactly the same to our application so if we change our stripe we change our PayPal stripe updates PayPal updates it doesn't matter nothing in our code will change inside of this store it will remain exactly the same so now that I've talked about what these different ideas are let's go into a concrete code example so here's a concrete version of that example where we have our store we have stripe we have PayPal which we'll look at it a little later and then some implementation detail actually calling that store so let's take a look at this code in depth we have our store which is going to take in a user it's going to create that new stripe object and this stripe class that I'm referring to here is you can imagine like the actual stripe API I obviously don't want to use the actual stripe API in this example so this stripe class here is essentially our version of the stripe API so just think of this as the stripe API for these examples and it'll make a lot of sense so we're creating an object that allows us to access the stripe API directly then we can purchase a bike in a helmet inside of this store and we're just calling the stripe API making a payment and a bike cost $200 so we're saying 200 times the price of the bike and since stripe always wants us to send the amount in pennies we multiply that by 100 so then we're sending them the amount of pennies it cost to buy this bike same thing for a helmet except for a helmet is only $15 instead of $200 now if we go to our stripe class you can see it takes in a user which is the user we're going to make payments on and then it's going to make that payment using the amount in pennies like I said and it just logs out that the user paid the amount of money they paid in dollars using stripe and we created a new store down here where John is going to buy two bikes and two helmets and if we save this you can see that since our bike cost two hundred and he bought two John made a payment of $400 with stripe and then since the helmets are 15 dollars and he bought two he's now made a payment of $30 with stripe so now let's say if this is working great everything's going well but striped changes their pricing and now stripe is really expensive to use so we want to switch over to paypal because paypal is really cheap it's way better for our business so we're gonna use paypal so now here's what the paypal api looks like it doesn't take in a user in that constructor it actually takes a user in the make payment method and it wants its amount in dollars it doesn't take it in pennies it takes it in dollars and then it of course logs out the exact same thing except for it's saying that it bought it with paypal so in order to use paypal inside of our application the first thing we need to do is to change our constructor we have to change this to save dot PayPal is going to equal to a new PayPal and since PayPal doesn't take the user object we can't send it so we have to also create a user variable here so this dot user equals new or equals user just like that let's comment out our stripe and then in order to make a payment with PayPal what we need to do is say this dot PayPal dot we want to do the price times the quantity and we need to also make sure we pass in this dot user and we need to do the same thing here with the helmet so we can say this dot PayPal dot make payment this dot user the price times the quantity and now if we save our code you'll see that it's exactly the same John made the 400 dollar payment with PayPal and he made the thirty dollar payment with PayPal and that was fairly painless to change over but you can imagine in a real application with a real store the amount of times that you have payment code is going to be a lot it's going to be all over the place and also the number of methods inside those API is going to be a lot more than one and there's probably going to be a lot more differences luckily we have two methods that both are called make payment which allow us to easily transfer between these two different api's you can imagine the way PayPal does payments and the way stripe does payments are going to be very different so making a transition like this is going to be really hard in most cases so what you want to do instead is to create some kind of intermediate API this is going to be your wrapper which is going to wrap around stripe and wrap around PayPal and the idea of this wrapper is that it has the exact same functions the exact same methods the exact same interface so in our store we never have to change our store so let's imagine that we have a class called payment processor and we're just going to take in a user so we can say here payment process or just like that and then our payment processor is just going to have a function called pay and this function that's called pay is just going to take in the amount in so say 200 times quantity and we'll do the exact same thing down here except for we want to just pass in 15 times our quantity and we want to make sure this is the payment processor whoops payment processor dot pay so there we go now we have our code using this payment processor which always takes in a user in the constructor and it's always going to take in the amount in dollars for a function called hey and we want to have different payment processors one for stripe and one for PayPal which wrap these dependencies of PayPal and stripe so that we don't depend on the exact implementation of stripe or PayPal so let's create one first for stripe we're gonna call this our stripe payment processor whoops and our stripe payment processor just like we mentioned earlier is going to take in a user and it's going to set the user equal to user because this needs to match the API we created up here it's also going to have a function called pay which is the amount in dollars and all we want to do is call stripe so up inside of our constructor we can actually just say this dutch stripe is going to be equal to a new stripe we can pass in that user and we don't even need to save this user anymore and down in here we can say stripe dot make payment and we want to make sure that we make this payment in sense so we can say amount in dollars / or Sam sorry x 100 so now that we actually have this payment processor created what we can do is pass this payment processor into the store so instead of passing a user in here we're gonna pass in our payment processor and we don't need to create a new payment processor in the store anymore we could just set that to our payment processor now down inside of our store all we need to do is pass in our new stripe payment processor with the name of our user for example John and now if we save you see that this payment processor that we created for stripe is passing off all of our function calls to the stripe API out here and you can see it's printing out the proper information on the right hand side of the screen and the best part is is we can create another payment processor if we just copy this for PayPal and all we have to do is change this single line down here where we instantiate a paypal processor instead of a striped processor so let's create that paypal processor just like this and we want to first set our user so we're going to set it to the user we got passed in and now inside of this pay function we want to make sure that we call that PayPal API so we'll create the PayPal API up here just like that and it doesn't take in a user as you remember so now we can say this dot paypal dot make payment and we want the amount to be in dollars and we want to pass in the user just like that and now if we save and come down here and change this to our paypal processor you'll see that we're getting an error and that's just because we need to make sure we use this dot user inside of our make payment function and now we'll we save you see John is able to make that payment through PayPal and this other payment through PayPal and we didn't have to change any of the code inside of our store this all stayed exactly the same because we have this payment processor interface work method or abstraction whatever you want to call it that is allowing us to not have to change any of this code and all we need to do is create a new payment processor wrapping the API we want to use and then we just pass that into the store down here this setup is very similar to the facade pattern or the adapter pattern which I have videos on the facade pattern you can check out I'll link in the cards in the description down below and that's all you need to know about the dependency inversion principle if you enjoyed this video make sure to check out my other solid design principle videos linked over here and subscribe to the channel for more videos just like this one thank you very much for watching and have a good day

Channel: Web Dev Simplified

Views: 156,109

Keywords: webdevsimplified, SOLID design principles, SOLID design, SOLID design tutorial, SOLID design example, SOLID design explained, SOLID principles javascript, SOLID principles js, solid tutorial JS, javascript, SOLID, js, dependency inversion principle, dependency inversion, dependency injection, dependency, dependency inversion js, dependency inversion solid, dependency inversion javascript, dependency inversion js principle, dependency injection js, dependency injection javascript

Id: 9oHY5TllWaU

Length: 13min 0sec (780 seconds)

Published: Tue Jan 28 2020