Comment by tyleo
3 months ago
I don’t think I’ll ever understand the affinity for DI libraries. I write a lot of tested code but it’s always just plain old interfaces and constructor arguments for me.
Other parts of our org use a DI framework and I feel like it causes a new class of dependency ordering bugs or missing dependencies. These just don’t exist when everything is passed in the ctor.
That's something DI does sure, but Spring for example is a fully managed way of talking about stuff in your app. It exposes universal APIs to talk about all the things, and the ways of making things, and config for things. It lets you see what stuff is made.
I've found there to be something radically compelling about all the hooks Spring allows into it's runtime. The sub-interfaces of Aware offer all sorts of ways to see what is in your runtime, see things getting constructed, see other parts of the lifetime of things.
Asking the container for a thing is the most well known use case, but there's so so much we can learn about our environment at runtime by having these managed containers. Programming used to hint at "Meta-Object Protocols", more expansive forms of objects, and Spring for example delivered us something like that: a higher level better modeled object (and factory and other pieces) than what the runtimes gave us.
> I’ll ever understand the affinity for DI libraries
DI addresses/can address/affects more than 10 different aspects of application lifecycle. We've described our reasoning in several talks linked at https://github.com/7mind/izumi?tab=readme-ov-file#docs
> I feel like it causes a new class of dependency ordering bugs or missing dependencies
That's precisely where phased approach shines.
I looked at the link you shared but it’s just a page of additional links.
Can you provide specific examples here instead?
What I think is most useful in cases like this is before-and-after code snippets showing how the library adds value.
There are docs and examples here: https://izumi.7mind.io/distage/
Not in before-after form though, but there was that "I'll eat my hat" discussion exactly in this form: https://www.reddit.com/r/hascalator/comments/aigfux/comment/...?
2 replies →
Agreed. Modern Spring brags about not requiring pages of external XML files like it did in the old days. But plain constructors is still an improvement on both.
Configurable apps (see "axis" and "role" concepts in distage) are prohibitevely hard to setup and maintain, dual test with sound opt-in memoization are, probably, practically impossible.
So I looked at the examples and it just seems like a lot for a little.
https://izumi.7mind.io/distage/basics.html#activation-axis
I feel like all you need there is a ctor param that takes a greeter and pass in whichever you want.
Those params can be cached as necessary or part of larger config POD objects if they are often passed with other dependencies.
1 reply →
It just gets rid of the boilerplate. Never had a problem with ctor injection in Spring.