Hacker News Reader

Comment by doctor_eval | Hacker News Reader

I’m sorry, but in my experience, dependency injection in Java was a total nightmare for reasoning and maintainability on anything but trivial projects.

We just keep inventing special ways to make things more complex and magic, when what we really need is to accept that simplicity is a virtue.

View on HN

Dependency injection isn't even needed if code is written functionally. After all, nothing needs to be "injected" if the function where the dependency being used isn't even called in the first place; you simply pass dependencies as arguments when needed. But communities like Java are so dedicated to OOP that highfalutin ideas like dependency injection are not only treated as necessities, but as good things.

I don't see dependency injection as a good thing. It's complexity added to try and make up for other complexities. I've never seen a dependency injection system implemented in any language that wasn't unnecessarily difficult to understand or that didn't have gotchas. All of that wouldn't be needed if most things were written as functions (i.e. no ImageThumbnailHttpUploader class), or if class instances were always invoked directly without magic.

Passing a dependency or lambda as a function argument is dependency injection. What is different is the implementation. There's lots of dependency injection in pure functional programs it just doesn't look like how a typical Java project does it.

I've grown to dislike Spring DI, Google's Guice and friends. You can use basic constructor injection and wire it up in your main method with zero dependencies or framework and it ends up simpler, easier to reason about. Java has also had Lambda's for a long time now so sometimes all you need to do is pass in a Lambda.

The other day I had to make a change to a java file for my first time in my life in my work. I only needed to set a boolean to true in a builder. I had to: 1. Create a new annotation in some random file 2. Import said annotation in another file 3. Use a dependency injection decorator on a constructor parameter with my new annotation 4. Require said parameter via another decorator in a class method 5. Finally use the value inside the method

This is even a simplification. Just why...

Currying is just a poor man's dependency injection, just as closure is a poor man's object (and vice versa).

Seems more the other way around: Closures require extra automatic (and possibly "unsanctioned" memory usage, gasp) and largely requires good garbage collection, what are you, rich? Currying requires even more closures, and sometimes closures of closures, do you think this house is made of money? Abstractions like functors and monads have large learning curves and smell too much like math and you need some sort of University degree to understand them, right? Money doesn't grow on trees here in the real world, pal!~

> or if class instances were always invoked directly without magic.

Then you can't provide a test seam.

Dependency injection + mocking is a very powerful concept.

Sure you can. Class constructors are still a thing.

> Sure you can. Class constructors are still a thing.

Definitely. I do 99% of my dependency injection as constructor "injection".

Injection frameworks and Whitebox testing just introduce layers of complexity that can be very difficult to debug

> Sure you can. Class constructors are still a thing.

Definitely. I do 99% of my dependency injection as constructor "injection".

Injection frameworks and Whitebox testing just introduce layers of complexity that can be very difficult to debug

Reply on news.ycombinator.com