Hacker News Reader

Comment by laureny | Hacker News Reader

Not a single mention of Guice or even dependency injection?

Seems like a gaping omission in a guide that claims to be about "modern" Java.

Dependency injection and any othee type of code indirection is evil imo. Anything that breaks the ability to find your way in a codebase with something other than grep brings more pain in the long run than it saves.

> the ability to find your way in a codebase

It's a tradeoff between two different kinds of clarity. Yes, it's harder to see the "whole wiring" without better tools...

But it makes small, encapsulated classes much easier to reason about and develop! You can focus on assuring: "My `Foo` can interact with a supplied `Bar`" rather than dealing with all sorts of crap about what implementation of `Bar` it gets or how that `Bar` instance is configured.

grep is a that good even for for c++ or dynamic mojo. Java is statically typed and has many ides and tools that understand code structure.

isn't that good

Just grep for "extends InterfaceBeingUsed" and you'll find the implementation just fine.

Dependency injection has seen its day. The gains promised by DI/IoC containers tend to be outweighed by the complexity they introduce.

I'm looking at you, Spring.

Spring's DI is terrible but Guice (and on mobile, Dagger) is really easy to work with, statically typed and has increased the maintainability and testability of our code base tremendously.

Adding @Inject is hard now?

Most DI frameworks automatically configure, and register objects. So literally all you need to add is the annotation.

Then you can override the automatic registration with you own, with different implementation when required.

DI is fine, it's just the way people overuse it that's an abomination. I general inject the most significant pieces, or the pieces that are changed. I won't even introduce DI unless I know I'm going to setup a different config of it. My coworkers (sigh), insist that nearly everything must be injected to "eliminate dependencies". (and because it makes it "easier to test"). YMMV

Dependency injection is an abomination. Working on DI code feels like slogging through the post-processed expansion of some more elegant language. It's hard to understand control flow, and DI adds exciting failure modes to otherwise-correct code. Don't forget that DI also bloats class and method counts.

Substitution for testability should be done at the runtime level, substituting class references as needed, instead of punishing all production code everywhere.

> Substitution for testability should be done at the runtime level, substituting class references as needed

That would require a Java agent. And that's a smell it its own right. (Cf JMockit)

Coming up in part 3, where we discuss http services.

Reply on news.ycombinator.com