Dependency Injection Frameworks are absolute shit. I have yet to encounter one that doesn't make code take hours to understand or debug, and usually requires a debugger to even begin to unravel it. Not to mention the "context" god objects that just are glorified versions of passing an array from function to function. You guys aren't avoiding global state you're just making it a clusterfuck. Stop being stupid for 2 minutes software development "progress" challenge. Level: impossible.

I would say if you are working on a server running on a framework that has built in dependency injection.

The built in stuff is useful. Getting fancy with it is when things starts to go weird.

Always glad I had DI. Never had problems. What are you doing? :D

Can it be complicated.... Yes.

But have you ever worked with the pre DI frameworks, e.g. in PHP Zend Framework Registry?

Believe me, I choose DI over this any time...

DI feels natural in statically typed code. Has nice DX in Java or PHP. It's a solution to a problem that may be solved in a more flexible way with composition in languages that provide the proper tools for it.

Inversion of control is desirable for "strict", unambiguous implementations (eg a SOAP client), whereas flexibility is preferable for a code which may be used in many different ways (eg a build tool). And that is why you should choose metalsmith.js over nuxt or nextjs for your static sites (shameless plug) :D

Dependency Injection is great, but it doesn't require a framework. In even the most rigid OO languages you can just wrap your class in a generic factory parent class that's parametric over the implementations, and then instantiate it in whatever setup mechanism you employ. In flexible languages like Typescript you can wrap your modules in functions and because no types are statically known you don't even have to deal with a generic.

I firmly believe that frameworks and libraries exist to encapsulate complicated logic.

1. Referencing some external logic in a module but allowing the implementation to be chosen elsewhere, that's just a function.
2. Making the same choices everywhere where an instance of the module is desired, that's a parameterless function calling 1. with a constant
3. Specifying a single choice but retaining the right to modify it, that's a named constant.
4. Extracting the process of instantiating an interface with details provided by the current module but the process and exact class determined by the same logic that makes the choices outlined in 1, that's a factory callback function.

Your language may not call it a function, but it takes an input and produces an output, sometimes on the type level. Every language has them.

The only things in DI worth encapsulating are instance pool management strategies, but they can safely be made into individual libraries because 99.9% of use-cases demand strategies that can be described in 5-20 lines each.

New is glue.

DI is great. Unless used wrong. Why is it hard to debug / follow?

tsyringe

@hypervtechnics most likely reading and using code someone like you made and claims they never had issue with. It's because you made it someone else's problem.

@IntrusionCM I haven't worked with Zend Framework Registry but I have worked on many frameworks, libraries and in house solutions for 15+ years. Using something like Magento2 makes me want to not use something like Magento2 which leans heavily on it. In fact my company moved off of it due to many of its issues, their DI implementation only one of many reasons.

Wordpress doesn't use such systems and is better off for it. Neither did any C programs. DI is poo.

@progresshuh magento 2 is a very good example how not to design an architecture imho.

Wordpress... Oh no.

C doesn't have a DI is only half true. C has no object oriented programming, unless you add a library for it.

@progresshuh Well as I am mainly maintaining the applications I write I know this "someone else". Its me and sometimes a colleague. You can do a lot of things with DI and you can do a lot of complicated things (not doubting that, just nothing DI specific).

@IntrusionCM C manages to avoid a lot of bad things because it doesn't support OOP wonder why that is?

@progresshuh C also supports complex pointer manipulation.

I'm not sure if you are even talking about DI framework or the idea of dependency injection and inversion of control.

I mean that's what DI really is isn't it. Instead of passing in a pointer to function1, you pass in pointer to function2 but with the same arguments?

@progresshuh C doesn't avoid problems, it's incapable of implementing the solutions that entail those problems. It's like me not having to think about insurance because I can't afford a house.

@lorentz an apt analogy is creating a housing bubble from bad lending policies that you then try to fix with a bailout by giving money to some of the same people that created the situation in the first place.

C avoids the problems because it didn't create them. It's more than capable of solving any problem you give it. Programmers that solve problems they created aren't good programmers, since they're being paid to create and solve problems though they could be classified as con artists.

@iceb the complaint wasn't on something as simple as passing parameters to a class method or a function, it's on the clusterfuck of xml file configs, compiled classes, boilerplat vomit spit out by command line and context god objects many have turned it into and still call it a good thing. It is not.

@progresshuh aah gotcha.
I don't know which framework you are looking at.

fwiw. I was fine with the asp.net core one. (although I think they also support registering via xml, but simpler methods exist)