The discussion focused on efforts to separate Java programming from the nitty gritty details of threads. This separation allows a greater number of developers to successfully program for parallel environment by removing focus on the technical details, and thus reducing the knowledge required to write the code. There's also some coverage of the benefits of the higher level of abstraction of functional programming and how the functional programming style is being incorporated into the Java concurrency model. The text has this:

The future will be functional programming or won't be at all.

Intellectually, I applaud these efforts. Emotionally, I feel some loss.

My first introduction to threads was in a systems programming class, using the C language and Pthreads library. Pthreads blew my mind, or maybe it was lack of quality in the lectures. Either way, determined not to be defeated by Pthreads, I went out and bought a stack of books on Pthreads and threads in general and set out to wrap my mind around threads. It worked, but along the way, I learned that I loved the challenge and so I embraced concurrency and parallelism with much enthusiasm. This knowledge that I've accumulated will always be of great value, but as I move toward programming threads at further and further abstractions, I'll lose that close connection to the internals, and I'm a little saddened by that.

First, a couple of quick definitions from Wikipedia:

"Inversion of Control, or IoC, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to the traditional architecture of software libraries."[2]

"Dependency Injection (DI) in computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency."[3]

The two topics I want to hit on from Jordan's post are testability of code that's been subjected to IoC/DI and, more trivially, the naming of dependency injection.

What's in a Name?

The term "Dependency Injection" was first published by Martin Fowler, who writes "Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection."[4]

I can appreciate the desire to pin names onto various forms of IoC to separate them more clearly, but I disagree that the term "Inversion of Control" is a more confusing name compared to "Dependency Injection". What can be more clear than inverting control? I don't think dependency injection is anywhere near as clear. I'm probably not the first to say this, but inject it where exactly?

I was pleased to read that I'm not the only person in the world who's not thrilled with the DI terminology after reading Jordan's post[1]. I don't agree with everything he writes, but I'm also not thrilled with the term "dependency injection".

I'm going to use the term IoC going forward in this article, simply because that's the term I prefer. All examples are in Java, for simplicity, and also because most of the articles I read regarding DI/IoC are also using Java.

Testability and Maintainability

I agree that IoC makes unit testing easier, much easier, by allowing us to easily mock portions of our applications, as is nicely explained by Miško Hevery[5]. (JMock is a terrific mock library, btw) Repeatable unit testing is a huge advantage of IoC, but at the same time, it's also a huge disadvantage because IoC makes integration testing and debugging much more difficult. This is because it becomes much harder to trace through the code due to the decoupling.

Regarding decoupling, Jordan writes, "We need some coupling so that we can understand how classes relate to one another. Maintainers of a code base need to be able to discover how various classes relate to one another and be able to trace class usage and interdependence. Hiding all of this complexity in XML files and annotations leaves the application impenetrable."[1]

I've always been a big believer in "read the code" and I love to read code, even bad code, because much can be learned from code. "What happens when you read some doc and either it doesn't answer your question or is demonstrably wrong? In Linux, you say 'Linux sucks' and go read the code. In Windows/Oracle/etc you say 'Windows sucks' and start banging your head against the wall", wrote Denis Vlasenko on the lkml.[6]

The decoupled nature of IoC, though, can turn a simple code-reading into a huge time-sink. Rather than diving in for a good read, the developer struggles to find which concrete class is actually invoked, then must discover which project/package that code actually belongs to, and finally must locate the actual source code for that project/package in the revision control tree before she can even begin to read the code.

I've experienced this first-hand in several different projects where I've taken over enhancing some code after a developer left the company, and it can be an exasperating experience. An enhancement is requested, or a bug is logged. Let's assume it's a bug. I might have been given an exception stack trace, and that at least gets me to a source code file to start from. I usually find a nice set of unit tests that I can run and quickly discover that they all pass - no big surprise there. They're all tests using mocked systems, though, so I'm unable to immediately reproduce the bug aside from being able to write a cute mock test to simulate how the code would respond to that particular error input, since I can easily mock the error. That's nice, but not very useful if my goal is to stop the error from happening in the first place.

Which concrete class is the actual perp? That's where it gets tricky. Most of the time, the stack trace gives no clue. Reading the code and examining XML files (or whatever method was involved for configuring the concrete classes used) can be a huge waste of time, and turns into a sort of tedious breadth-first search.

Is there a more direct way to find the perp? The best workaround I've found is to become very good with the debugger, and many times that means the remote debugger, and stepping deeply into the code until the likely culprit is found. That process will give a class name and package, but there's still some detective work to discover what project that belongs to. If you use version control and have lots of different projects created over many years of development with similarly named Java packages, that can be a nightmare, so let's just hope you work for a highly organized company that has everything documented in great detail so that finding the source code is a breeze.

The ability to quickly gather information and understand a program by reading the code is degraded by IoC because of the decoupling. It's important to recognize both the advantages and disadvantages of using IoC in your projects. I am a fan of IoC, but I always stop to give consideration for what future torture I may be inflicting on myself or others when I'm designing a project and try to plot the course with the minimum future pain.

Summary

Miško Hevery asks us this question, "Should I be using dependency-injection?"[7] My answer to that is yes, no, maybe. The pains "injected" into code maintenance and integration testing by IoC aren't enough to be deal breakers, but they do point out the need for documentation and evaluation. Document what concrete classes are used for what functions, what packages they're in, where to find the tree in your source code repository. Make sure your documentation is easily accessible and up-to-date (my preference - a wiki, but that's for a separate post). Evaluate your project and ask if it would benefit from IoC. How will it be tested, maintained and used in the future? Use IoC when there's a good justification for using it and then use it responsibly, don't just use it because it's the big buzz word that everyone's using and it'll look good on your resume.

[1] Dependency Injection Makes Code Unintelligible
[2] Wikipedia: Inversion of control
[3] Wikipedia: Dependency injection
[4] Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern
[5] Miško Hevery: How to Think About the "new" Operator with Respect to Unit Testing
[6] Top 50 Linux Quotes of All Time, #10 [note lkml == Linux Kernel Mailing List]
[7] Miško Hevery: When to Use Dependency Injection

Here's the mission of the group as given on their wiki page: "The Java Women Network promotes collaboration amongst women who develop and use Java technology to increase the visibility of women's contribution, mentoring opportunities and professional networking."