←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 1 comments | 18 Feb 25 16:55 UTC | HN request time: 0s | source
Show context
DrScientist ◴[19 Feb 25 10:34 UTC] No.43100646[source]▶
Never quite understood the attraction of dependency injection frameworks.

Sure pass in your dependencies as an interface via some sort of constructor, but why all the frameworks to do so?

Why all the complexity with hard to debug magic strings, annotations and finding out what's missing from the classpath at runtime?

Just seems as a very complicated way to avoid creating package c that brings together package a and dependency b in a simple class that creates b and passes it into a.

What am I missing?

replies(4): >>43100728 #>>43100842 #>>43102999 #>>43113106 #
1. mrkeen ◴[19 Feb 25 11:07 UTC] No.43100842[source]▶
I second this.

The original value proposition of DI (dependency inversion) was that you could write your tax logic and unit-test it without the code knowing that it's talking to MySQL. Injecting your dependencies into your constructor makes dependency inversion possible.

That messaging has somehow become smeared across dependency injection, frameworks, classpath scanning, autowiring, reflection, annotations etc.

20 years ago, DI meant that your TaxCalculator didn't know about your database.

Today, DI means that your TaxCalculator still knows about your database, but now it knows about Spring too.