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!
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
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.
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 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.
I love understanding dependency injection and writing Go. It makes the developer experience so much smoother, so much more fun. Really took my code and projects to the next level.
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.
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.
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!
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.
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 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.
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 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!
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!
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!
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!
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!
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#.
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
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
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?
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 !
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
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
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.
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.
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.
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 RUclips 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...
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 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.
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!
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'm a new ( < 1 Yoe ) SWE working on a large spring boot java codebase and the last part you mentioned about moving compile time errors into runtime has bit me more than once.
The solution is really simple: write unit tests. Write a test that calls your DI registrations, and then tries to resolve your root types. For example, if you have a MVC web application, write a test that checks that all of your controllers can be resolved, which by extension checks that the services they need can be resolved, etc.
I remember the days when OO was the hyped new thing, and UIs were turned full OO and the hype got so big that every pixel was put in it's own multiple-inheritance virtual class and whadaya-know, performance started suffering and changing the Pixel class required changing layers and layers of Interfaces. The solution was obvious. Buy pixel-servers! With complex load-balancing to make sure all pixels get updated in time. Ok, I may be exaggerating, but Dependency Injection is a genius idea. And thus, a great tool. But nevertheless, needs some moderation and contemplation to use without causing more damage than good.
The examples are in Typescript. `(c) => { /* logic */ }` is an arrow function expression (also known as a lambda or anonymous function depending on your language). In this case it is defining a function that accepts a parameter `c` and will execute some logic. developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
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!
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
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.
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 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.
I love understanding dependency injection and writing Go. It makes the developer experience so much smoother, so much more fun. Really took my code and projects to the next level.
This is by far the best explanation of dependency injection I've even seen. Thank you!
This is the best most straight forward of explanation of dependency injection. Great stuff.
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.
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.
I know about DI but this video has reinforced my understanding of DI as a subtypoe of IoC
This is one of the best videos you can find on DI period.
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!
Thank you so much for explaining dependency injection in the concise way.
As a beginner I Increased my knowledge base.
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.
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 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.
Your content is absolutely flawless. Please please please keep uploading.
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.
Wow, the ease of explanation you have is just amazing, clear, direct and concise, you have a new subscriber!
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 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!
finally an explanation that covers both sides of the debate. thanks :)
The world needs teachers like this
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!
thanks for that clear and concise explanation.
Just a small hint, at 3:29, there is a typo within "with".
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 ❤
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!
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!
I'm still in my early career and this really helped me understand when to use it and when not to. Thanks!
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#.
Excellent video.
Keep it up.
Hope you continue uploading about design patterns and programming paradigms.
Perfect explanation for DI & IoC. Thank you so much.
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
Wow. I love the way you explained. It is so easy to understand now. Thank you so much for your efforts.
Very good yet simple explanation of the topic! Would love to see other related videos on SOLID.
This is really good. Hope you'll make more content in the same format. Kudos
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
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
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?
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 !
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
Concise and good explanation, subscribed to see more of your content.
Never thought I'd learn dependency injection from Tom Hiddleston himself.
😂😂
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
By far the best explanation 🌟
Very good explanation and right on point! Thank you!
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.
You've got great presentation skills! Looking forward to more content how to make my dev life easier (especially QA part). Thanks
this is by far the best explanation of the topic, amazing job, thank you
Why can't we have more teachers like you in computer science?? Please make more videos!!
Great explanation 👍
Minor nit: "Separation of Concerns" is misspelled as "Seperation of Concerns" at 2:15.
Very insightful and succinct, love it!
Thanks for the video! I often use dependency injection in Angular, but don't understand meaning behind it.
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.
Great explanation, thanks 👍
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.
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.
Thank you. Great explanation.
very clear explanation thank you
I've always thought I hated DI, turns out I only hate DI frameworks, thanks for enlightening me 🙏
excellent breakdown!
Fantastic video and animation, keep it up!1
Amazing explanation, thanks!!!
dude it's very clear video
Plz make more videos about other programming concepts like this one.a playlist for OOP
Thanks, this was a great video.
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 RUclips served this video to me shortly after me thinking about that given that I didn't look anything up to find this :D
Hi Scott excellent work...please do videos on spring boot
Great video scott
Just amazing. Thanks a lot !
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...
oh, now I get the idea of this term. thank you!
Awesome video!
Make more 👍
0:30: "Spring", not "Swing". Spring is an extensive framework for Java. Swing as an old UI library.
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 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.
Nice and clear.
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!
Im gonna stick to my procedure code, keep my methods micro and build wrappers on these methods to get things done for individual cases.
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?
Line 5:23 Lethal Injection Exception
Gracias
I'm a new ( < 1 Yoe ) SWE working on a large spring boot java codebase and the last part you mentioned about moving compile time errors into runtime has bit me more than once.
The solution is really simple: write unit tests.
Write a test that calls your DI registrations, and then tries to resolve your root types.
For example, if you have a MVC web application, write a test that checks that all of your controllers can be resolved, which by extension checks that the services they need can be resolved, etc.
Great video. Subbed
A rising star on YT. wooooooohoooo
I miss (bigger) real life example here, besides that it's a really good video
I remember the days when OO was the hyped new thing, and UIs were turned full OO and the hype got so big that every pixel was put in it's own multiple-inheritance virtual class and whadaya-know, performance started suffering and changing the Pixel class required changing layers and layers of Interfaces.
The solution was obvious. Buy pixel-servers! With complex load-balancing to make sure all pixels get updated in time.
Ok, I may be exaggerating, but Dependency Injection is a genius idea. And thus, a great tool. But nevertheless, needs some moderation and contemplation to use without causing more damage than good.
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 thought its amental health issue 'bout abusive dependence.
@2:20 It should spell "Separation", not "Seperation"
Some hand-wavy philosophical advantages but the code is obscure and undebugable. Guess which side I'm on 😁
good one, keep on going
Rust isn't OOP language but widely uses this pattern too. Maybe you do not need to claim OOP. Otherwise your video is an excellent.
WHICH LANGUAGE IS THIS???
Also, what's (c)=> {
}
The examples are in Typescript. `(c) => { /* logic */ }` is an arrow function expression (also known as a lambda or anonymous function depending on your language). In this case it is defining a function that accepts a parameter `c` and will execute some logic.
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions