Re:Why I stopped using Spring
by ivan_gammel on Wednesday December 25, 2013 @01:57PM
(#6963837)
In good design the intent is clearly defined in interface on which you depend. If the code has side effects, if it does something not specified by interface, if it has more than one role, this code needs to be fixed and it is not a problem with DI. It's a problem with your design.
As I already said, you always need to wire your objects. You do it, possibly, without realizing it, but you still do it. If you reject the idea of DI just because the code is bad and DI is "Not Invented Here", you will not do the wiring better. Writting custom DI is hard, and it's very likely that you will end with unmaintainable nightmare that needs to be rewritten completely. For 15 years I've seen this nightmare too much and never seen the successful projects with custom DI.
So is DI a result of incomplete language design? Should the concept of DI be baked in?
Re:Why I stopped using Spring
by ivan_gammel on Thursday December 26, 2013 @04:17AM
(#6965724)
For enterprise software, for large projects, probably, yes. Together with more advanced reflection (I imagine MOF/EMF as a native part of Java) to allow meta-programming and smarter code generation.
Re:Why I stopped using Spring
by cstejerean on Wednesday December 25, 2013 @03:28PM
(#6964132)
My tools already do that. With IntelliJ and its Spring support I can easily jump directly to the actual implementation that is being wired in, just as easily as I would jump to source if it was a concrete class. But in a properly designed system I rarely need to go poking into the implementations of my dependencies.
I had an argument about DI with a friend months ago and it boiled down in his use (Guice) that it was only for testing components.
I think of DI as a big meta-constructor in the sky, it gives dynamic scope to a lexically scoped language. And the problem with it as we currently use it, is that it hides intent behind a config file so we can't read what the code is actually doing, only doing abstractly.
What if the tooling ghosted those abstract classes and put the concrete classes in their place with reading and navigating? It could effectively "statically link" in the IDE those dependencies.