I've been developing professionally for 6 years and nobody so far during my education or work have been able to explain dependency injection to me in a way that was understandable for me. This video is fire honestly
tbh dependency injection is just a fancy name for passing a value to a function and that value serves the purpose of abstracting the logic away from the function you are passing it into
@@esteban4983 so true. Also, callbacks and IoC are not necessary for reusability and low coupling. More over, IoC tend to harm humanly understandable control flow and cause bugs. From the video i see how to resolve basic SRP violation by delegating responsibility to another object. And that's done with "IoC". But you can just use dependency passed through constructor and that's it. And more, doing this way you move Billing dependency from the Checkout interface to concrete realization details. And that's a big deal for Checkout users. So, is there any point for following IoC? Or we can just use DI with straight control flow without brain inversion?
@@nilpunch2 by "just use DI" do you mean using the constructor? if so, yes I agree. More so, callbacks make it harder to test and at least in OOP I would use the constructor to pass dependencies and not to the method itself
FINALLY! Someone who knows this stuff and can explain it to people that are skeptical. I like the thorough coverage of IoC and DI and how they relate and their goals and purposes and ultimate practical implementation. I like that you pointed out how the abstraction of DI frameworks merely converts code to data, not reducing the complexity much, while introducing some of its own. Bookmarked this in case I have to deal with a fanatic. Thank you!
been using nestjs more and more in my backends, and once i realized what the "magic" was under the hood - dependency injection - it was easy to see why it was needed, and i learned to implement it by myself using the good old expressjs in a couple pet projects. having it all setup for you is great, but learning how it actually works so you can confidently keep using such an opinionated framework knowing "the opinions" is way better.
I've been doing Rust for a bit more than 2 years now, and honestly every video I watch that introduces a programming technique makes me understand better just why Rust is so beloved. This one is no exception. So in Rust DI is most commonly done using traits (basically interfaces in OOP lingo). A great example of this is the `Write` trait: it allows a single generic piece of code to write into basically anything - a file, a network stream, a memory location, a deserialiser, and more. And since it's such a core part of the language, the entire library ecosystem is interoperable via traits like this.
People really underestimate how useful the testing aspect is. I work everyday with codebases which range from 10+ years old to just a few months old. The older stuff that didn't plan for DI is such a bitch to test because we can't pass in custom mock services, still trying to fight to let me rewrite these
out of the 5 short videos about Independency injection I just watched I got the most from this one. This is thanks to: 1) a big picture being brought - a bit of history and reason behind the DI technique, together with an architecture of the system; 2) the graphics of the tree of classes vs. when the DI has been implemented. Thank you for creating this. I find it helpful
wooooooowwww!! just like almost everyone else is saying, I couldn't find one person who could explain me what dependency injection is and you've explained it so nicely in this video in fact! I've used this while writing code for a checkout service which uses different payment gateways without knowing it!!!! that was a wonderful coincidence
DI is one of those things that really make me appreciate functional languages like Haskell. Since functions in Haskell are themselves first-class values, you can easily invert control or abstract some functionality by writing a function which accepts other function(s) as argument(s). So rather than designing and instantiating lots of interfaces and classes that all depend on and call back to each other in intricate ways, all I need to do is directly reference the callee function I want the caller to use. You can also do similar abstractions at a type level if you take advantage of typeclasses and data families. I really recommend that anyone interested in this tries out functional programming. It's very different from what you might be used to, but also has a wealth of new ways of looking at programming problems to offer.
I never learned all the design patterns of OOP, was mostly self-taught and had to write complex scientific simulation software using R (of all languages -.-). I read most of Hadley Wickham's book "advanced R" at the time and then just wrote code the way it made sense to me. Every so often I come across videos like this where some concept is explained and I realize, I've been writing code using these patterns without ever thinking about whether or not they exist. DI was something so obvious to do in languages like R, where functions are both input arguments to functions as well as return values of them. (Wickham calls them functionals and function operators). It all felt natural to me and made sense. Never thought there were some grand design deliberations behind such simple approaches.
While this originated in functional languages, you can do this in most languages these days. And heck, you can even do it in plain old C with function pointers or if you use Apple's clang extensions, block pointers that can capture lexically local references
I have a hard time imagining it makes the logic easier to reason about, but I could see how that would be cleaner than a language where functions are treated as object members.
DI and IoC always sounded like complex terms to me, but your explanation made it so simple to see! You have a great way of explaining things, and the editing really makes it pop out! Thank you! Hopefully you do more design patterns, or honestly anything really.
Amazing explanation🎉 The additional downside of using DI libraries is that these libraries have APIs that keep changing and one has to spend a large amount of time keeping the code current to keep up with the changing APIs and the annotations associated with them. Additionally, these libraries create a ton of generated code that is harder to debug and they also have defects which manifest in concurrency and race conditions
The inversion of control example you gave was really eye-opening for me. I never never thought to have a function that is just meant to gaurd clause or handle logic before executing an important function. Personally, I find that extracting that type of function to resolve to a boolean if the logic is passed or not is a lot simpler than taking in a callback.
I've been using dependency injection since I started working as a software engineer 5 years ago, I didn't even know that there are people who don't use it, particularly I find it very simple to debug, group and configure application dependencies, especially when you understand the life cycles of each type of dependency.
As other have said, this is by far the clearest explanation of dependency injection and inversion of control and the rationale for them I have seen. Also very concisely laid out arguments for and against use of dependency injection frameworks. You got yourself another subscriber!
Thanks, your explanation is perfect for newbie like me who is still confused with so much jargon or terminology in these architecture framework things. I subscribe!
I use dependency injection, it was difficult at first to understand this simple notion, that all the resources to be used in the application are initialized by a container, and only injected when needed to be used. But now that I understand that I really like using dependency injection. Also, thank you for such an illuminating share of knowledge in your video, Scott.
This is a better explanation of why dependency injection exists than I ever heard in my years of being forced to use Dagger. I still think the majority of problems it solves are better solved with procedural programming but at least I understand it now.
Thank you for the great explanation. I'm new to programming and DI sounded quite complex when I first heard of it. But your explanation made it much easier to understand. Thanks a lot!
I started learning DI a couple days ago and I think is a easy to understand, but a little hard to put in practice. I'm programming in C# and Microsoft DI library has some features like the lifetime of the dependency etc (Scoped, Transient...).
I agree, I find the trickiness comes from the particular dependency injection library you are using as each has their own “quirks and features”. The general happy-path mostly just works, but sometimes, even when you are familiarized with the library, you can get bit by the abstraction layers hiding a little too much and leading to some obscure bugs. Two fun stories from production: When I was at Google, one of my teams ran into rolling out-of-memory crashes in our fleet of servers. Memory usage would increase predictably, correlated with QPS before a crash and restart. We eventually traced it down to the dependency injection library (Guice) instantiating a particular class with each request, which in turn would do a lot of heavy memory allocations. Once we realized that, it was an easy fix, but it was non-obvious when looking at the code because the instantiation path was abstracted away. Another fun one: Angular has a built-in dependency injection library that on the surface looks pretty straight forward. However, a lesser known fact is that behind the scenes Angular generates a tree of Injectors that inherit from each other. In certain cases you can end up with what you thought was a singleton service instantiated multiple times across this injector tree. In my case I ended up with 2 duplicate caches that slowly would come out of sync and would manifest as unusual behavior in the UI. Took me long time to track down!
If you write your classes to contain no mutable state and only pure functions, you can simplify all of this to just using the singleton lifetime. At that point, classes are really just modules. You don't have to worry as much about thread safety, race conditions, excessive allocations, etc. You get a lot of the advantages of functional languages, make the code easy to test and modify, while keeping the syntax of C#.
Great explanation! I’ve been working with Laravel for nearly a decade, but only really started exploring the Service Container recently. It has a great implementation and relies heavily on DI to make testing and mocking very developer-friendly. Your video helped me understand it better conceptually, thanks!
Well, I certanly hope more contento from this guy. So clear and easy to understand such an important concept! Keep the software engineering concepts comming!
This is such a good overview description of this concept. Great job. I sent this link to the devs on all my teams. Instead of diving into more Angular videos have you considered similar videos for some of the other SOLID principles?
Thanks for sharing. I've been considering doing more general software engineering videos now. This video actually started as an Angular video that I broke up because it was getting too large!
Thank you so much for this video you made things a lot easier please stop whateever ur doing lol and start a carreer on youtube because man your the best i already tried many video but once i saw your everything is clear now
wow, a really well done video ! While I find dependency injection super useful is writing modular code, not a fan of the DI libraries i've used so far, in the JS ecosystem. However, with Typescript 5 bringing decorators to stable, I'm keen to see if there is an uptick in these projects !
I'm starting off with my SDE journey with nestjs. Its what I call DI and boilerplate hell, with hard to decode error traces. But i do get the appeal of having modularity & scalability with lots of verified library support right out of the box
inversion of control? Yes! I think every time I write a `.map` it's technically IOC. But I used a library with decorators for NestJS and wasn't a huge fan for the exact reasons you mentioned. It felt like it made things really hard to grok without much benefit.
When I was asked this question on an interview, landed my first job btw, I thought it was about npm dependencies lol. And even though I worked on the project, Typescript with jQuery and lots of libs, I never understod it. Forward to today where I use PHP OOP and I have worked with dependency injections I understand it a little bit now. I think more experience is needed working with frameworks as well but this is a great video
Awesome video, keep the good work! I hope we will have more videos like this one across the youtube and learning concepts becomes more engaging and exciting
Great, only thing I missed was the explanation on "where the dependecies of a class comes from?", just to explain every dependecy tree has a tip that needs to be the starting point of the execution so the dependecy tree can be resolved and wired. Still, loved it.
Use inversion of control a decent amount with functional components in React and occasionally when there's heavy stuff I want to use without having to have much "passing aroound" code (i.e. boiler plate) I remember about how 5 years ago I learned Angular 1 and 2 (in the same 6 week course! - odd) - and I recall that Angular 2 had "dependency injection". So ocassionally I wonder if that would have helped me in those moments, but mostly I'm happy with React so I haven't checked yet. - Funny that TH-cam served this video to me shortly after me thinking about that given that I didn't look anything up to find this :D
Personally, I tend to prefer implementing this inversion of control via the abuse of dynamic and static link libraries. This essentially offsets all the glue code to the compiler and operating system. Do I have a function that may require swapping the implementation at some point? It's a library. Statically-linked libraries will trigger compiler errors if the interfaces don't match up, too. Though I don't really practice these principles often. It just isn't practical when people follow principles just because they think they should. I analyze the needs and requirements of the software and follow whatever principles will suit it the most. And also focus on not coding myself into a corner...
In code interviews they always ask “what is dependency injection” and I still struggle to answer it. I know why we do it, I just can’t find the words. I think ctos get too hung up on details like that
I think if I had to distill it to the simplest form: It's a pattern where instead of classes instantiating their dependencies, they are provided to it in the constructor. This makes the code more flexible. Then you could always drill into the benefits or specific framework the interview is asking about.
Dependency injection via constructor or some builder pattern is very useful; it makes testing using doubles a breeze, makes it easier to make big changes later if needed. I really don't get why anyone wants to use frameworks though. Why would I want to learn another language then not be able to figure out what is wrong when my code isn't working as intended? If you use good naming and follow SOLID principles why would you want to make your life hard again?
I think dependency injection is unfortunately named. First times i heard of it, my mind instantly related it to SQL injection, just because of the naming, and as such saw it as something negative. First when I sat down and investigated what it was i realized my mistake!
What frameworks or patterns would you recommend for JS/TS? I recently tried out inversifyJS, but decided not to use it, due to some the issues you mentioned, namely confusing rules about what gets injected where, lack of type safety for injected items, and, as a corrolary, many compile time errors becoming runtime errors. Plus it's basically unmaintained afaict.
I've personally tried tsyringe, typedi and typed-inject, which are all good and you should check them out in case you haven't, specially typed-inject which doesn't use decorators which may be seen as an advantage since now that decorators are in phase 3, some things that did exist back when those libraries were manteined now don't exist, such as parameter decorating. What I ended up doing is to just pass the dependencies via constructor and move dependencies to more abstract things like interfaces to avoid circular dependencies. The JS/TS DI ecosystem is not well developed yet compared to other languages like Java, so this approach ended up being one of the best solutions for me.
I used it the first time now in C#, but not sure if I like it. I have to register ALL services on startup and when I need it I can take it via the constructor. Sure this is somehow "magic" because I can do it where ever I need it. But registration and taking it via constructor is in fact more code than just = new MyClass(); whenever I need it. Or make it even static if I don't need instance vars. Also if Class1 needs a function from Class2 and vice versa DI fails badly because of a infinite loop. Without DI (or even with) I can just create a new instance. So what is the benefit?
I've always thought it was weird that there is this weird name people give to what is basically just passing interfaces or functions into a constructor. Basically every modern statically-typed language has first-class functions and some kind of interface/trait/abstract class concept. Just use them? It's weird to me that there are libraries for this. Maybe I'm missing something.
I used callbacks as an example for inversion of control here because they make a nice self contained case. You’ll often see the pattern playing out in a bigger scale in frameworks or larger libraries where the frameworks are calling into your code to perform some action, then control flow goes back into the framework An example would be something like a web server (like express.js) where you define custom handlers and tell it how it should process http requests. Or something like React/Angular where your components can have life-cycle hooks. They invert traditional control flow because the library is calling you instead of you calling the library.
I agree with Nathan. IOC is a pattern of having the callee defer to the caller, with one of the more common examples being frameworks (the callee) deferring to custom bits of logic being provided (by the caller). I do agree that coroutines and async code also impact control flow. However, I don’t see the two at odds with each other, rather as tools for different situations. You could design a library that uses IOC as a design pattern for customization while at the same time using coroutines for async work.
I worked for 5 years in a Java Spring environment and while I did understand the @Autowired annotation and the like, I never truly knew the definitions As for whether I like the pattern or not - I love it. I hated the codebase though because the people who wrote it originally made it a monolithic app that took 5 minutes to spin up... which you would need to do every time you make a server change. I don't see why dependency injection would be bad if had a well designed microservice architecture.
React dependency injection doesn’t exist in this way. We use context, hooks, imports and pass by props. It’s arguably simpler in many ways. It’s dependency injection in a different form.
I've been developing professionally for 6 years and nobody so far during my education or work have been able to explain dependency injection to me in a way that was understandable for me. This video is fire honestly
I don't get it but this seems like a reason for me to save this video for a later time.
tbh dependency injection is just a fancy name for passing a value to a function and that value serves the purpose of abstracting the logic away from the function you are passing it into
@@esteban4983 so true.
Also, callbacks and IoC are not necessary for reusability and low coupling. More over, IoC tend to harm humanly understandable control flow and cause bugs.
From the video i see how to resolve basic SRP violation by delegating responsibility to another object. And that's done with "IoC". But you can just use dependency passed through constructor and that's it. And more, doing this way you move Billing dependency from the Checkout interface to concrete realization details. And that's a big deal for Checkout users.
So, is there any point for following IoC? Or we can just use DI with straight control flow without brain inversion?
@@nilpunch2 by "just use DI" do you mean using the constructor? if so, yes I agree. More so, callbacks make it harder to test and at least in OOP I would use the constructor to pass dependencies and not to the method itself
I feel sorry for whoever's been employing you to "develop professionally" when you don't understand fundamentals of your field.
I've been a developer for 24 years professionally, and no one has ever explained IoC and DI this clearly. Well done!
FINALLY! Someone who knows this stuff and can explain it to people that are skeptical. I like the thorough coverage of IoC and DI and how they relate and their goals and purposes and ultimate practical implementation.
I like that you pointed out how the abstraction of DI frameworks merely converts code to data, not reducing the complexity much, while introducing some of its own.
Bookmarked this in case I have to deal with a fanatic. Thank you!
One of the best explanations on the topic that also addresses the pros and cons objectively and concisely. Outstanding job!
Clear and concise explanation with examples that are relatable, cheers Scott!
been using nestjs more and more in my backends, and once i realized what the "magic" was under the hood - dependency injection - it was easy to see why it was needed, and i learned to implement it by myself using the good old expressjs in a couple pet projects.
having it all setup for you is great, but learning how it actually works so you can confidently keep using such an opinionated framework knowing "the opinions" is way better.
I've been doing Rust for a bit more than 2 years now, and honestly every video I watch that introduces a programming technique makes me understand better just why Rust is so beloved. This one is no exception.
So in Rust DI is most commonly done using traits (basically interfaces in OOP lingo). A great example of this is the `Write` trait: it allows a single generic piece of code to write into basically anything - a file, a network stream, a memory location, a deserialiser, and more. And since it's such a core part of the language, the entire library ecosystem is interoperable via traits like this.
People really underestimate how useful the testing aspect is. I work everyday with codebases which range from 10+ years old to just a few months old. The older stuff that didn't plan for DI is such a bitch to test because we can't pass in custom mock services, still trying to fight to let me rewrite these
out of the 5 short videos about Independency injection I just watched I got the most from this one. This is thanks to: 1) a big picture being brought - a bit of history and reason behind the DI technique, together with an architecture of the system; 2) the graphics of the tree of classes vs. when the DI has been implemented. Thank you for creating this. I find it helpful
Thank you so much for explaining dependency injection in the concise way.
As a beginner I Increased my knowledge base.
wooooooowwww!!
just like almost everyone else is saying, I couldn't find one person who could explain me what dependency injection is and you've explained it so nicely in this video
in fact! I've used this while writing code for a checkout service which uses different payment gateways without knowing it!!!!
that was a wonderful coincidence
DI is one of those things that really make me appreciate functional languages like Haskell. Since functions in Haskell are themselves first-class values, you can easily invert control or abstract some functionality by writing a function which accepts other function(s) as argument(s).
So rather than designing and instantiating lots of interfaces and classes that all depend on and call back to each other in intricate ways, all I need to do is directly reference the callee function I want the caller to use.
You can also do similar abstractions at a type level if you take advantage of typeclasses and data families.
I really recommend that anyone interested in this tries out functional programming. It's very different from what you might be used to, but also has a wealth of new ways of looking at programming problems to offer.
I never learned all the design patterns of OOP, was mostly self-taught and had to write complex scientific simulation software using R (of all languages -.-). I read most of Hadley Wickham's book "advanced R" at the time and then just wrote code the way it made sense to me. Every so often I come across videos like this where some concept is explained and I realize, I've been writing code using these patterns without ever thinking about whether or not they exist. DI was something so obvious to do in languages like R, where functions are both input arguments to functions as well as return values of them. (Wickham calls them functionals and function operators). It all felt natural to me and made sense. Never thought there were some grand design deliberations behind such simple approaches.
While this originated in functional languages, you can do this in most languages these days. And heck, you can even do it in plain old C with function pointers or if you use Apple's clang extensions, block pointers that can capture lexically local references
I have a hard time imagining it makes the logic easier to reason about, but I could see how that would be cleaner than a language where functions are treated as object members.
Your content is absolutely flawless. Please please please keep uploading.
DI and IoC always sounded like complex terms to me, but your explanation made it so simple to see! You have a great way of explaining things, and the editing really makes it pop out! Thank you! Hopefully you do more design patterns, or honestly anything really.
This is by far the best explanation of dependency injection I've even seen. Thank you!
Amazing explanation🎉 The additional downside of using DI libraries is that these libraries have APIs that keep changing and one has to spend a large amount of time keeping the code current to keep up with the changing APIs and the annotations associated with them. Additionally, these libraries create a ton of generated code that is harder to debug and they also have defects which manifest in concurrency and race conditions
This is one of the best videos you can find on DI period.
I know about DI but this video has reinforced my understanding of DI as a subtypoe of IoC
The inversion of control example you gave was really eye-opening for me. I never never thought to have a function that is just meant to gaurd clause or handle logic before executing an important function. Personally, I find that extracting that type of function to resolve to a boolean if the logic is passed or not is a lot simpler than taking in a callback.
I've been using dependency injection since I started working as a software engineer 5 years ago, I didn't even know that there are people who don't use it, particularly I find it very simple to debug, group and configure application dependencies, especially when you understand the life cycles of each type of dependency.
This is the best most straight forward of explanation of dependency injection. Great stuff.
finally an explanation that covers both sides of the debate. thanks :)
The world needs teachers like this
As other have said, this is by far the clearest explanation of dependency injection and inversion of control and the rationale for them I have seen. Also very concisely laid out arguments for and against use of dependency injection frameworks. You got yourself another subscriber!
Never thought I'd learn dependency injection from Tom Hiddleston himself.
😂😂
Thanks, your explanation is perfect for newbie like me who is still confused with so much jargon or terminology in these architecture framework things. I subscribe!
I use dependency injection, it was difficult at first to understand this simple notion, that all the resources to be used in the application are initialized by a container, and only injected when needed to be used. But now that I understand that I really like using dependency injection. Also, thank you for such an illuminating share of knowledge in your video, Scott.
This is a better explanation of why dependency injection exists than I ever heard in my years of being forced to use Dagger. I still think the majority of problems it solves are better solved with procedural programming but at least I understand it now.
Thank you for the great explanation. I'm new to programming and DI sounded quite complex when I first heard of it. But your explanation made it much easier to understand.
Thanks a lot!
I started learning DI a couple days ago and I think is a easy to understand, but a little hard to put in practice. I'm programming in C# and Microsoft DI library has some features like the lifetime of the dependency etc (Scoped, Transient...).
I agree, I find the trickiness comes from the particular dependency injection library you are using as each has their own “quirks and features”. The general happy-path mostly just works, but sometimes, even when you are familiarized with the library, you can get bit by the abstraction layers hiding a little too much and leading to some obscure bugs.
Two fun stories from production:
When I was at Google, one of my teams ran into rolling out-of-memory crashes in our fleet of servers. Memory usage would increase predictably, correlated with QPS before a crash and restart. We eventually traced it down to the dependency injection library (Guice) instantiating a particular class with each request, which in turn would do a lot of heavy memory allocations. Once we realized that, it was an easy fix, but it was non-obvious when looking at the code because the instantiation path was abstracted away.
Another fun one: Angular has a built-in dependency injection library that on the surface looks pretty straight forward. However, a lesser known fact is that behind the scenes Angular generates a tree of Injectors that inherit from each other. In certain cases you can end up with what you thought was a singleton service instantiated multiple times across this injector tree. In my case I ended up with 2 duplicate caches that slowly would come out of sync and would manifest as unusual behavior in the UI. Took me long time to track down!
If you write your classes to contain no mutable state and only pure functions, you can simplify all of this to just using the singleton lifetime. At that point, classes are really just modules. You don't have to worry as much about thread safety, race conditions, excessive allocations, etc. You get a lot of the advantages of functional languages, make the code easy to test and modify, while keeping the syntax of C#.
Great explanation! I’ve been working with Laravel for nearly a decade, but only really started exploring the Service Container recently. It has a great implementation and relies heavily on DI to make testing and mocking very developer-friendly. Your video helped me understand it better conceptually, thanks!
I love Laravel ❤
Well, I certanly hope more contento from this guy. So clear and easy to understand such an important concept! Keep the software engineering concepts comming!
Wow, the ease of explanation you have is just amazing, clear, direct and concise, you have a new subscriber!
I'm still in my early career and this really helped me understand when to use it and when not to. Thanks!
thanks for that clear and concise explanation.
Just a small hint, at 3:29, there is a typo within "with".
As a beginner for the first time I feel like I understood what an DI really is!
Im liking your down to earth approach at explaining im subbing lol
Perfect explanation for DI & IoC. Thank you so much.
Excellent video.
Keep it up.
Hope you continue uploading about design patterns and programming paradigms.
This is such a good overview description of this concept. Great job. I sent this link to the devs on all my teams. Instead of diving into more Angular videos have you considered similar videos for some of the other SOLID principles?
Thanks for sharing. I've been considering doing more general software engineering videos now. This video actually started as an Angular video that I broke up because it was getting too large!
Thank you so much for this video you made things a lot easier please stop whateever ur doing lol and start a carreer on youtube because man your the best i already tried many video but once i saw your everything is clear now
Why can't we have more teachers like you in computer science?? Please make more videos!!
By far the best explanation 🌟
this is by far the best explanation of the topic, amazing job, thank you
Very good explanation and right on point! Thank you!
This is really good. Hope you'll make more content in the same format. Kudos
Wow. I love the way you explained. It is so easy to understand now. Thank you so much for your efforts.
wow, a really well done video ! While I find dependency injection super useful is writing modular code, not a fan of the DI libraries i've used so far, in the JS ecosystem. However, with Typescript 5 bringing decorators to stable, I'm keen to see if there is an uptick in these projects !
I'm starting off with my SDE journey with nestjs. Its what I call DI and boilerplate hell, with hard to decode error traces. But i do get the appeal of having modularity & scalability with lots of verified library support right out of the box
very clear explanation thank you
Very good yet simple explanation of the topic! Would love to see other related videos on SOLID.
inversion of control? Yes! I think every time I write a `.map` it's technically IOC. But I used a library with decorators for NestJS and wasn't a huge fan for the exact reasons you mentioned. It felt like it made things really hard to grok without much benefit.
Thank you. Great explanation.
excellent breakdown!
When I was asked this question on an interview, landed my first job btw, I thought it was about npm dependencies lol. And even though I worked on the project, Typescript with jQuery and lots of libs, I never understod it. Forward to today where I use PHP OOP and I have worked with dependency injections I understand it a little bit now. I think more experience is needed working with frameworks as well but this is a great video
dude it's very clear video
oh, now I get the idea of this term. thank you!
Awesome video, keep the good work! I hope we will have more videos like this one across the youtube and learning concepts becomes more engaging and exciting
Great explanation 👍
Minor nit: "Separation of Concerns" is misspelled as "Seperation of Concerns" at 2:15.
You've got great presentation skills! Looking forward to more content how to make my dev life easier (especially QA part). Thanks
Great video scott
Just amazing. Thanks a lot !
Great, only thing I missed was the explanation on "where the dependecies of a class comes from?", just to explain every dependecy tree has a tip that needs to be the starting point of the execution so the dependecy tree can be resolved and wired. Still, loved it.
Thanks, this was a great video.
Concise and good explanation, subscribed to see more of your content.
Very insightful and succinct, love it!
Fantastic video and animation, keep it up!1
Nice and clear.
Amazing explanation, thanks!!!
Thanks for the video! I often use dependency injection in Angular, but don't understand meaning behind it.
Gracias
I've always thought I hated DI, turns out I only hate DI frameworks, thanks for enlightening me 🙏
Hi Scott excellent work...please do videos on spring boot
A rising star on YT. wooooooohoooo
Great explanation, thanks 👍
Use inversion of control a decent amount with functional components in React and occasionally when there's heavy stuff I want to use without having to have much "passing aroound" code (i.e. boiler plate) I remember about how 5 years ago I learned Angular 1 and 2 (in the same 6 week course! - odd) - and I recall that Angular 2 had "dependency injection". So ocassionally I wonder if that would have helped me in those moments, but mostly I'm happy with React so I haven't checked yet. - Funny that TH-cam served this video to me shortly after me thinking about that given that I didn't look anything up to find this :D
Awesome video!
Make more 👍
Personally, I tend to prefer implementing this inversion of control via the abuse of dynamic and static link libraries. This essentially offsets all the glue code to the compiler and operating system. Do I have a function that may require swapping the implementation at some point? It's a library.
Statically-linked libraries will trigger compiler errors if the interfaces don't match up, too.
Though I don't really practice these principles often. It just isn't practical when people follow principles just because they think they should. I analyze the needs and requirements of the software and follow whatever principles will suit it the most. And also focus on not coding myself into a corner...
Plz make more videos about other programming concepts like this one.a playlist for OOP
In code interviews they always ask “what is dependency injection” and I still struggle to answer it. I know why we do it, I just can’t find the words. I think ctos get too hung up on details like that
I think if I had to distill it to the simplest form:
It's a pattern where instead of classes instantiating their dependencies, they are provided to it in the constructor. This makes the code more flexible.
Then you could always drill into the benefits or specific framework the interview is asking about.
Line 5:23 Lethal Injection Exception
Dependency injection via constructor or some builder pattern is very useful; it makes testing using doubles a breeze, makes it easier to make big changes later if needed. I really don't get why anyone wants to use frameworks though. Why would I want to learn another language then not be able to figure out what is wrong when my code isn't working as intended? If you use good naming and follow SOLID principles why would you want to make your life hard again?
I think dependency injection is unfortunately named. First times i heard of it, my mind instantly related it to SQL injection, just because of the naming, and as such saw it as something negative. First when I sat down and investigated what it was i realized my mistake!
What frameworks or patterns would you recommend for JS/TS?
I recently tried out inversifyJS, but decided not to use it, due to some the issues you mentioned, namely confusing rules about what gets injected where, lack of type safety for injected items, and, as a corrolary, many compile time errors becoming runtime errors. Plus it's basically unmaintained afaict.
I've personally tried tsyringe, typedi and typed-inject, which are all good and you should check them out in case you haven't, specially typed-inject which doesn't use decorators which may be seen as an advantage since now that decorators are in phase 3, some things that did exist back when those libraries were manteined now don't exist, such as parameter decorating. What I ended up doing is to just pass the dependencies via constructor and move dependencies to more abstract things like interfaces to avoid circular dependencies. The JS/TS DI ecosystem is not well developed yet compared to other languages like Java, so this approach ended up being one of the best solutions for me.
I used it the first time now in C#, but not sure if I like it. I have to register ALL services on startup and when I need it I can take it via the constructor. Sure this is somehow "magic" because I can do it where ever I need it. But registration and taking it via constructor is in fact more code than just = new MyClass(); whenever I need it. Or make it even static if I don't need instance vars. Also if Class1 needs a function from Class2 and vice versa DI fails badly because of a infinite loop. Without DI (or even with) I can just create a new instance. So what is the benefit?
great video but maybe check how your audio levels compare to other youtubers you watch..i had to turn my volume up quite a bit
I've always thought it was weird that there is this weird name people give to what is basically just passing interfaces or functions into a constructor.
Basically every modern statically-typed language has first-class functions and some kind of interface/trait/abstract class concept.
Just use them?
It's weird to me that there are libraries for this.
Maybe I'm missing something.
Great video. Subbed
Im gonna stick to my procedure code, keep my methods micro and build wrappers on these methods to get things done for individual cases.
It’s just a fancy name for “callbacks”.
I used callbacks as an example for inversion of control here because they make a nice self contained case. You’ll often see the pattern playing out in a bigger scale in frameworks or larger libraries where the frameworks are calling into your code to perform some action, then control flow goes back into the framework
An example would be something like a web server (like express.js) where you define custom handlers and tell it how it should process http requests. Or something like React/Angular where your components can have life-cycle hooks. They invert traditional control flow because the library is calling you instead of you calling the library.
@@ScottABailey That kind of pattern of ongoing sequence of actions is commonly handled nowadays by async code--i.e. coroutines.
@@lawrencedoliveiro9104 Coroutines are about concurrency. DI about giving the caller the power instead of the callee
@@NathanHedglin Maybe you should reread the response from @Scott Bailey above, talking about “inversion of control”.
I agree with Nathan. IOC is a pattern of having the callee defer to the caller, with one of the more common examples being frameworks (the callee) deferring to custom bits of logic being provided (by the caller). I do agree that coroutines and async code also impact control flow. However, I don’t see the two at odds with each other, rather as tools for different situations. You could design a library that uses IOC as a design pattern for customization while at the same time using coroutines for async work.
thank you
I worked for 5 years in a Java Spring environment and while I did understand the @Autowired annotation and the like, I never truly knew the definitions
As for whether I like the pattern or not - I love it. I hated the codebase though because the people who wrote it originally made it a monolithic app that took 5 minutes to spin up... which you would need to do every time you make a server change.
I don't see why dependency injection would be bad if had a well designed microservice architecture.
0:30: "Spring", not "Swing". Spring is an extensive framework for Java. Swing as an old UI library.
Some hand-wavy philosophical advantages but the code is obscure and undebugable. Guess which side I'm on 😁
I miss (bigger) real life example here, besides that it's a really good video
As a web dev, having to create multiple pages, I solely depend on DI.
great video
good one, keep on going
2 words: Elixir/Erlang, ETS. More functional/data drive less issue.
React dependency injection doesn’t exist in this way. We use context, hooks, imports and pass by props. It’s arguably simpler in many ways. It’s dependency injection in a different form.
Moving from Symfony to working on a chaotic legacy application with no framework... I so miss Symfony's "DI Container".