Dependency Injection is not only about compile time dependencies
Tinou complains that dependency Injection was broken. I want to add some points to his / hers statements:
The problem I’ve always had with DI frameworks, be it Spring or Guice, is they create this nasty dependency tree. If you don’t want to use GlobalApplicationContext.getBean() or Injector.getInstance() then you’ll need to inject all your dependencies at the root. It annoys the crap out of me, but I suppose there’s just no way around it…
Except if the language had a mechanism to realize interfaces and abstract classes at runtime, either built-in or through some extension.
[…]The fundamental problem with all dependency injection tools is they are trying to do what language should be doing (instantiating objects that implement some interface[!]).
These toughts might be correct if you reduce dependency injection to “instanciate a class that implement this or that inferface”. But I understand dependency injection as a tool for inversion of control and decoupling of implementations. Dependency injection shall enable the developer to reconfigure the application without compilation of the compontents that depend on eachother.
Yes, at some point you will have to decide which implementation of a certain interface shall be used, and one can argue where this “wiring information” should be placed: Spring uses an XML file, PicoContainers can be composed hierachically, guice can use annotations. But if you have only one implementation of the interface you can do without a dependency injection framework at all.
Updates
- Fixed typos
- As pointed out by Paul Hammant PicoContainer of course can be configured with XML as well as with Groovy, Python, Beanshell and Ruby. I’m sure one can add Yaml and Json easily as well. Furthermore I think this is possible to some extend for Spring and Guice as well and the Qi4J developers would be able to add something to this, too. What I wanted to make clear is that one can argue about when, where and how to wire the components; the different ways the mentioned frameworks offer emphasize this.
If found this content useful consider “buying me a beer” with PayPal (Suggested 2,50 € for a Beer).
-
@Rickard: If fully agree with you. Calling the process “reassembly” emphasises that this is not meant for end-user. I had a deeper look into Qi4j and it’s on my tools to use list.
September 18th, 2005 at 9:30 pm -
I think most people generally get the terminology wrong about what a change of implementation means. You call it a “reconfiguration”, but to me “configuration” is something the end-user of the software does, and as an end-user of any software I would never want to deal with changing implementations of whatever. That is a developer task. In Qi4j we would call this “reassembly”, which is separate from configuration, and is done by Assemblers. The API for Assemblers in Qi4j is programmatic, but that obviously means that an Assembler could read any configuration file to choose implementations. In general we don’t recommend it, as having class names in text files generally tend to make refactoring harder, and easy refactoring is something we really really strive for as it is a basic tenet of Domain Driven Design.
September 19th, 2005 at 12:46 am
Subscribe by RSS