I recently attended a St. Louis Java User's Group meeting where Alex Miller discusssed the various forms of dependency injection. It was a great talk, and it got me to thinking.
I believe the problems we have with dependency resolution (which dependency injection attempts to solve) are not the real problem, they are the symptom. The real problem is that we have no ontology* for a running Java program except for the static package/class hierarchy. There is no practical mechanism for identifying objects within a running JVM, such that we could then describe how those objects should find things they depend upon (for an example of a failed attempt to do this, check out the Java Beans Activation Framework).
When I instantiate a "Widget" object, there is no notion of geography in the JVM. As a result, there is no way for me to say that the Widget instantiated "over here" should use the "Cog" object "over here", while the Widget instantiated "over there" should use the Cog object "over there". The problem is that there is no notion of "over here" or "over there" within the JVM. The general problem of no geography leads to specific problems like dependency resolution, when you want to reuse the Widget class and need to resolve dependencies the Widget has when instantiated. It's particularly difficult when you might have more than one Widget in the same running JVM and need them to use different dependant objects.
Essentially, we need a good ontology for objects in a JVM, and the one we have, the fully qualified class name, is completely inadequate since it is a compile-time characteristic.
We don't need dependency injection solutions. We need ontologies to describe the objects in a running JVM. This will make solutions to dependency injection trivial. It will also facilitate lots of other useful things, because it will give us a runtime geography that allows us to describe (and therefore group) objects based upon their 'location' in the JVM at runtime.
Now all we have to do is figure out the right runtime geography/geographies to support.
*The hierarchical structuring of knowledge about things by subcategorising them according to their essential (or at least relevant and/or cognitive) qualities. --The Free On-line Dictionary of Computing, © 1993-2004 Denis Howe
Subscribe to:
Post Comments (Atom)
5 comments:
What?
does not compute.... may be you should write it in clearer english... hiding behind the phrase "we need an ontology" is completely vacuous.
The comments so far seem to be hung up on the words (particularly "ontology") rather than the thoughts behind the words.
Lets see for "ontology" we could try:
"cataloging structure"
"semantic framework"
"taxonomy"
hmmm.. not helping, eh? Still searching for "le mot juste'.
Interesting read. I have 2 questions:
1) How do you define ontology and/or "runtime location" in Java/the JVM?
2) What kind of mechanism do you suggest for defining an object's ontology?
3) What would a unit test for a Widget (which depends on a Cog) look like?
--Aslak Hellesoy
I find it useful to define a Domain class and have all other objects reachable from there. Is that what you meant?
Post a Comment