Today we'll talk about using dependency injection across paradigms! You'll understand what this pattern is all about and how to use it.
During the episode, we'll touch on topics such as inversion of control, high-order functions, and testability.
Transcript
Episode 17 - Dependency Injection
00:00:02 - 00:05:06
welcome to the programming podcast. Here you can learn about computers in the brief and accessible way I'm your host mean could get. Hello everyone and this episode of the programming podcasts. We are going to discuss one of the most. Poke your bottles in software. Engineering congenital cooled dependency injection by the end of this episode. I hope I'm going to show you how simple this pattern and also how applicable across different parts a lot of people associated dependency injection only with object oriented programming. But in fact it is very usable across party lines. It is very applicable in functional programming. As well so in this show we give you an overview how he can use it across paradigm what this pattern s whether it's advantages and disadvantages to start with a very simple definition. So let's suppose that we have on obstruction and we can call this obstruction e client. This client does something and in order to do the stink it also delegates this execution to other obstructions which are its dependencies so dependency injection instead of asking the client. Stan sheet is dependencies by itself. We're passing them as parameters and that's it you mentioned that I didn't mention the word class or object even the single time of course in object oriented programming. This abstraction is probably represented with a close but in functional programming. We can represent this abstraction with the function. Rose I dig into depends injection from the view of an object oriented developer so as I mentioned this obstruction is a class there and we can think of this class. Let's say as a button. We may want to render this button on different platforms. We we may want to render it into the common line interface. Or why not onto a canvas? So in this case the bottom can depend on a particular render a seal. I render or a counter surrender. Imagine we ask this bottom two NS insanity it's render by itself. Well just means that our butts from now on depends only on the render or only owns the campus render. It can depend on any of these two because the particular instance that it uses is already decides at design time so we cannot change it at runtime at all but on the undersides we may have our implementation of the button and this can depend on an abstract class or even the new trophies called render this render just represents a very high level abstract interface for rendering something onto the screen whilst we instead of sheet our button we can pass a particular implementation of this render to its constructor and this way the button can use this particular implementation of their under from now on for rendering stuff onto the screen. See how we can use now the button with Paul's the Cli render and with the chemistry under without changing as well. We're just changing the way that we stand cheating the bottom passing different implementation of this abstract. That's pretty much all of it but imagine how your dependency grasp gets pretty big. So you're button. Depends on this. Render your render depends on different subtractions. Day depends on different drivers on how they're talking to the operating system. Let's say and so on and so forth it's certain point. With just a huge dependency graph. It might be really hard for you to track water dependencies across different abstractions in your system it also may get tricky for you to install sheets individual obstructions you need to think a lot about what are their dependencies and should something else happen. Before is down sheets there's dependency Q. Like create any other obstruction sets well in these cases is very convenient for you to take advantage of dependency injection framework this way instead of his town. Sheeting old these abstractions yourself. You're delegating depends injection framework which implemented so-called inversion of control. So you're inverting the control instead a few being responsible or the particular obstruction being responsible for instance sheeting as dependencies. Now someone else is responsible for this. And this is the inversion of Control. So-called container if you're using anger well.
00:05:06 - 00:10:05
I'm giving an example with dangerous as the framework that I'm working on. We can think of this dependency injection like inversion of control container as an injector. We have this injector era key in anger. We have different providers which are pretty much instructions on how you can use ten shady individual abstractions and they also configured a dependency graph of your applications. And if you won't Stan. She ate a particular attraction from the ones that you have what you should do. You just take the injector and ask for obstruction that you want. The injector is going to figure out water. All the dependencies of European extraction their transitive dependencies and so on and so forth is going to stand. She them one by one falling there to plunge order and finally you're going to get the instals that you ask for that's it. That's everything. Let us look at dependency injection from the context of functional programming. Now since we're talking only about functions and their arguments are button is going to be simply a function still if we want to make it cross platform button. We have to pass the rendering function as an argument and here it is a high order function a function that we can pass as an argument to our button so the consumer of the button can decide which rendered passed as an argument to the button. It can pass either. Just he'll render or tacoma surrender and this is already dependency injection it is really convenient for just swapping the actual concrete implementation dependency of of our abstraction and altering is behavior. That's it now. Let us briefly discuss water different pros and cons of using die? Obviously you're not coupled to a particular concretely implementation of your dependencies. You already so how we can render our button onto Komo interface and also onto a canvas by depending on the abstract render. Instead of depending on the particular implementation of the render and instance sheeting is our inside hard button itself so so far so good but this one really power. For implication it is during testing now imagine our button now depends on the service which makes him online purchase over AMMOS. Api so every time when you pick the button you're purchasing anew toward a paper package why not so you press the button and you get an order for a toilet paper baggage so he also have tests for does button and these tests are pressing the button so imagine now you open the poor request and your test run in circles every time when your test presses the button you're going to get a new package of toilet paper from Amazon. This is probably something that you don't want especially if you have lake tests and you have to restart your theory often instead. What you would want to do is ask her button to depend on an abstraction which can be implemented by your particular by from Amazon concrete implementation. And once you depend on this obstruction at this time you can pass a fake implementation of obstruction. That doesn't do anything. You just registers that you have purchased something but without actually the actual purchase on Amazon. So that's it see how powerful it is during testing. You might just see you might be thinking now. Yeah I can do that for sure but I can also monkey patch my toilet paper purchasing service instead you can definitely do that and this is an option. Monkey patching is always alternative. They namic languages such as Jealous Crypt. It's questionable whether it's more peer but it depends on the engineers preferences now wasn't a disadvantages of dependency injection. The source sometimes might be harder to understand you mentioned you have a large dependency graph if you want to stand sheet. A particular abstraction from dependency graph by using dependency injection container. It might be hard to figure out where it goes dependencies from it might really hard to trace the actual installation order and also you may need to pay upfront cost in order to understand your dependency injection framework because it has its own. Api you're bringing some extra weights pretty much as you're bringing a third party software as part of your abrogation. Those pretty much everything I wanted to talk to you about today. I hope you enjoyed this episode about dependence injection and until next time bye bye.
00:10:07 - 00:10:18
Learn about the episode's You can follow me on twitter at an get you. There is always ursus and recordings is available at podcast dot M. dot com. Thanks for listening.