The Real Inversion of Control

A recent conversation with my friend and colleague Erik Meijer provided the nudge to finally write about something has been bothering me for some time. So here it goes…The popular view about Inversion of Control (IOC) is that it represents a technique for removing dependencies in object-oriented programs. People immediately think of their favorite dependency injection framework, whatever that may be. That’s nice and well, but is that the real IOC?Consider the following:

  • XML was pitched as a language specifically designed to make parsing easy so developers would not have to write another parser. That has happened allright, very few worry about parsing XML today. However while computers spend less cycles parsing well-formed markup, people crippled their languages with angle brackets, end tags, and a verbose syntax. This in spite the fact that the number of language users > number of XML parsers.
  • Good SOA design recommends building stateless services. Service implementations that follow these guidelines retain nothing from one invocation to another. However while the services do almost nothing to maintain the state of the service conversation, the developers building service consumers picked up the tab. Again, the number of service consumers > the number of services.
  • Web browsers allow people to interact with applications through widgets such as text boxes, radio buttons, check boxes, buttons, and a few more. These widgets are so primitive that they easily map into the native widgets provided by the virtually all contemporary host environments. However while the browser happily renders widgets with consipcuous text UI era traits, developers jumped through many hoops to push the user experience closer to what the platforms have been providing for years. And you guessed it, the number of web applications > the number of browsers.

There are other examples but I’ll stop at 3. The commonality across them is that in each case the software is simpler somewhere because many developers picked up the tab somewhere else. Instead of localizing complexity and putting the machines to work so we could enjoy other, more interesting challenges, the opposite happened. We now have to write in a verbose, ugly-looking language that the software can easily process; manage the state of service conversations so the servers would not bother about it; use plugins and pull lots of strings to give the user experience a face lift so the browsers do minimal processing and rendering; and so on. So consider this other way to look at IOC: the software is in control, and we’re working for it. Darn did I take the blue pill?

Leave a Reply