Live data from Hacker News

The problem with dependency injection frameworks

jamesshore.com

91–92 of 92 posts

Re: The problem with dependency injection frameworks

#91
post #35

I advise to try build-time DI frameworks, like Dagger, see how it generates the glue code, and then ditch it and write the same glue code yourself. Yes, build-time cannot do tricky cases (when it depends on some runtime-only thing), but I'm yet to see any case of that. Build-time is also easier on JIT compiler, as there's no reflection involved in runtime, for VM it's all just hardcoded.

I prefer koin instead. It does no magic. It's simple function calls packaged up as a nice Kotlin DSL. Pure declarative. Easy to debug. It does not even use reflection. I've used it with ktor, and with kotlin-js in a browser (it's a kotlin multi platform library). There's basically no overhead relative to the code you'd otherwise be writing manually. I'm not an Android developer but I hear it's pretty popular there as…

Koin is all about Android. I tried it briefly, but all the examples don't work for me, e.g. 'by inject()` looks cool, if it worked, but it doesn't, because it requires a Class parameter. Inconveniently, no examples show what to "import" as well.

Re: The problem with dependency injection frameworks

#92

Earlier quoted context omitted.

Or they use macros (e.g. in C++) to create something you can't reasonably read through.

> Or they use macros Dark magic is still magic...

Until it's Heavy Wizardry and/or Deep Magic.
Post reply on HN