Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

> Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application

What does "decoupled" even mean anymore? That sounds like the opposite of "decoupled" to me.

(/not a Java programmer).

View on HN

Everything is wired up using Dependency Injection. So you just state your claims and are given appropriate objects that may be created by some third party factory factory. It's really neat until it isnt.

It's there an unspoken rule about how much dependency injection is too much dependency injection? Like I can see how it could get bad, but how do you know when you've gone too far?

Probably as soon as you don't know why an object appears in your tree. I'm not at all an expert on Di as the only project I worked on that used it a lot, I was also responsible for refactoring it such that spring di was only optional by annotated constructors, because spring startup is atrocious and we wanted to use part of the application in lambda.

I've not used it since because the project I inherited suffered extremely from nih syndrome.

The logic seems to be that having X use Y if it's available at runtime is less coupled than having X hard-depend on Y at build time. But IME the end result is similar to a "distributed monolith": you haven't actually decoupled it, you've just swept the coupling under the rug.

I guess it means that dependencies are hidden now.

Reply on news.ycombinator.com