6 ms·
You're 100% right. People that complain about DI don't understand 2 simple facts: 1) that graph of object creation is NOT equal to graph of object usage 2) if
by ivanche 6y ago
You're 100% right. People that complain about DI don't understand 2 simple facts:
1) that graph of object creation is NOT equal to graph of object usage
2) if you don't use DI, problems won't automagically go away - code will _still_ have dependencies, just they'll be hidden and tightly coupled
- mrits 6y agoIt sounds like it's you that does not understand there are alternatives.
- zzbzq 6y agoI 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 6y agoIt'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 6y agoThat's the point I'd like to see discussed. What's wrong with hard-coding "new".
- sharpercoder 6y agoThat 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 6y ago> 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 6y agoSo 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 6y agoMiško Hevery had explained it better than I ever could: https://web.archive.org/web/20200506032508/http://misko.hevery.com/2008/07/08/how-to-think-about-the-new-operator/ https://web.archive.org/web/20200506032508/http://misko.heve... https://web.archive.org/web/20200502175326/http://misko.hevery.com/2008/09/10/where-have-all-the-new-operators-gone/ https://web.archive.org/web/20200502175326/http://misko.heve...
- christophilus 6y agoI spent maybe 15 years using C# and DI (for most of that time), and understand it pretty well. I still dislike it. > just they'll be hidden and tightly coupled They're more hidden with DI than without, in my experience. At any rate, having left the .NET stack around 5 years ago, I certainly don't miss DI. My current code has more and better tests than my C# code ever did, so DI didn't really help me there (nor did it hinder me-- it was neutral). But my current code is much more explicit, direct, and a fair bit more compact. I'm definitely happier with it.
- ivanche 6y agoCompare 2 classes. Class A expects all its dependencies to be passed as constructor parameters. Class B has a default no-arg constructor, but buried inside 5 of its methods calls Dep1 dep1 = new Dep1(); or Dep2 dep2 = new Dep2(); Now, which class has obvious and loosely coupled dependencies? Which class has hidden and tightly coupled dependencies? To me, answer is clear - class A has obvious and loosely coupled ones. Lo and behold, class A comes from program which uses DI. Class B doesn't.
- apta 6y agoWhich stack did you move to?