Yes, incredible what years of Java Enterprise can inflict to the brain :-). It reminds me of the whole dependency injection circus where in the end it's just the equivalent of passing a function constructing an instance to another function in FP.
except the container can do whatever mumbo-jumbo you may want/need, like declarative transactions, declarative permission checks, logging, publishing events to external systems, etc.
and then you have async constructed dependencies, for example when you need to ask some server for configuration first, before service can be started, and with a good DIC the whole app will just wait automatically and you don't have to worry about any of that anywhere in your app (aka you are abstracted from this)
what you have said is not technically wrong but it also over-simplifies what DI is and it brings to the table
EDIT: that said, I agree in general, that java projects are over-engineered
Most of these things can be done with higher-order functions too.
I think that if Java had had lambdas earlier, Spring and other such frameworks might look very different. You can see that already, Spring is adding (experimental?) support for more declarative styles of configuration instead of the rather slow and hard-to-debug reflection magic: https://github.com/spring-projects-experimental/spring-fu
Yes but unfortunately I don't see how it invalidates my point.
a) you either replace DIC with custom hard-wired functions (composed using any-order custom helpers) and then it's still hard-wired at one place
b) you reinvent DI with functions but it's still some magic, late-configurable, easy-to-plugin container (aka the circus which I think you were referring to and which I have said it's actually useful and worth)
Yes, you do need a certain level of indirection to achieve the things you mentioned without polluting your code with non-business concerns such as transactionality. But the key differences are:
1. Application startup is faster because you avoid reflection.
2. It's type-safe because you avoid reflection, so you get compile-time errors instead of startup errors (or worse, startup errors only in certain configurations).
3. It gives you more inspectable behaviour. You can see how the entrypoint of the application wires together components. A lot of this can be hidden, spread out over multiple places and hard to understand otherwise.
Also, I'm not the person you originally replied to, didn't call DI a circus, and actually think that DI is a useful concept per se (that some FP purists maybe under-appreciate): It could just IMHO be done in a cleaner way (and a more deliberate way, not everything needs to be wrapped in 5 layers :)) with functional constructs instead of reflection hell. :D
