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 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.

I love Laravel ❤

😂😂

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!

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#.

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 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.

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.