[zzbzq]

I hope that's a typo because it's literally the opposite of what you're saying in #2.

It is precisely when you use a DI container that the problem is hidden, whether or not it's solved.

In most projects that use a DI container, the problem is usually not solved correctly, but the developers are oblivious and overconfident. They think, as you do, using a DI container means they did it right. False! The DI container only guarantees everything is hoisted up to the object constructor. This is NOT DEPENDENCY INVERSION. The objects can be in the constructor, but the dependency arrow can still point the wrong way. An obvious example of this I've seen a million times is an interface sitting right next to its only implementation. That's NOT Dependency Inversion.

If you don't use a DI container, the problem also may or may not be solved, but it is never obscured, it is completely visible.

[ivanche]

It's not a typo - without DI (i.e. by using new operator freely whenever dev feels like) code still has dependencies, just this time hard-coded and invisible until you read the source.

Also, one can use DI without DI containers. Actually I prefer not using DI containers when possible.

[didibus]

That's the point I'd like to see discussed. What's wrong with hard-coding "new".

[sharpercoder]

That multiple usages of the same concrete types requires changes on multiple places. For small programs, the di container itself can probably be skipped (i.e. instantiate an object graph by newing up). For larger programs, this is too cumbersome and therefore error-inducing.

[didibus]

> That multiple usages of the same concrete types requires changes on multiple places

Write a util function then, or like some like to call it, one of the many Factory pattern.

[shireboy]

So then you’re writing your own one-off DI of sorts. And you have more code to write than if you’d just used DI.

[ivanche]

Miško Hevery had explained it better than I ever could:

https://web.archive.org/web/20200506032508/http://misko.heve...

https://web.archive.org/web/20200502175326/http://misko.heve...

[didibus]

Yup, unit tests, and in my mind, that's bad. There's two reasons:

#1 Because the language provides no means to arbitrarily mock fields of a class, an entire design pattern and framework needs to be created just to do so. Why can't the language just have such a feature?

#2 This actually temps people in building worse design, because instead of creating pure units that don't have dependencies to begin with, it facilitates the opposite of creating deeply nested chains of dependencies, because "DI framework wires it up for me". Where if you didn't have that luxury, you'd be pushed towards pure units that don't have state dependencies, and integ tests instead, which in my mind is much better overall.

[ivanche]

#1 is just moving the goalpost. You jumped from "why new is bad" to "why can't language mock fields".

#2 What stops you from creating a complex system without having dependencies, thus avoiding DI? Also, I think it would make an interesting case study if you're willing to write it.

[didibus]

> #1 is just moving the goalpost. You jumped from "why new is bad" to "why can't language mock fields".

I don't think I did. Someone says, well if you use new, how are you going to unit test your class?

And one answer from a user of the language would be: Ya, I guess you'd need to change the way you're creating dependencies so they happen in the caller, and then you'd need to change your class so it takes the instance on its constructor, etc.

And this is the original OPs issue with C#, all the ceremony involved.

Another answer would be that the C# language designer could build a language level feature that avoids having to do that and allows mocking new inside a unit so it can be easily tested without shenanigans.

In fact, in Java-land, there is a library that lets you unit tests classes that use new, it's called Powermock. So it is feasible.

> #2 What stops you from creating a complex system without having dependencies, thus avoiding DI? Also, I think it would make an interesting case study if you're willing to write it.

I've moved to a functional language instead personally. That said, I do still like C# and Java, and think they are great languages. I'm also not against DI, or other enterprise patterns, some have legitimate uses. But I have definitely seen what the OP is complaining about, those languages are too deep in their own rabbit hole sometimes. To the point that half the developers don't know why they use DI, that's just part of the template they used to bootstrap their app. There's no thought process about, wait, what is the issue in my code structure and design that I'm facing, and what could I do to solve it. Instead it's just, I'm using all the "best practices", they are the best, and I'm using them all, all the time, so my code is the best it can be. Without any thought about what advantages they're even getting out of it.

That's why I asked about the "new". Most people don't really know the pros/cons. They only repeat what they read blindly: "New" bad bad, no use "new", never, very bad, antipattern, here link proof, must use DI instead.

And sometimes when they know of a cons, they don't think about tradeoffs against alternatives. They just say, well it has this one con, so it's very bad! An antipattern!

I think that creates a setting where you get monstrous framework and code bases, where people just throw every known pattern at it, no matter if it was called for or not.