Bin thinkin bout Inversion of Control:

BEFORE: “Containerless” — (not IOC), “Main” code kicked off, initialises objects, invokes first methods, off you go! Other objects create new objects, and create relationships between themselves…

Configuration is read by objects, and is ‘passive’ (used-by).

AFTER: IOC: Configuration is used by ‘application environment’ to ‘plumb’ a system together, instantiating objects and creating dependencies between them, invoking methods as described in the configuration.

In a sense, Configuration is ‘active’, and drives the system.

Of course, a text file is not active itself, but the ‘container’ or ‘application server’ uses it.

The configuration is declarative, not procedural

That is, instead of everything starting by normal imperative programming instructions, creating objects, and invoking methods in sequence, a 4GL (e.g.written in an XML language) describes what the system looks like and the dependencies between object creation, destruction and method invokation the application server sets it up, and ‘works it’ as described, ensuring all dependencies between components are resolved in the correct order.

Here’s an IOC:

• I want a system which has a KeyboardListener, a DisplayDriver, a GUI and a StartupAndShutdownController
• Start up the StartupAndShutdownController as soon as possible. Use ‘Start’ method.
• Register KeyboardListener to be notified by StartupAndShutdownController when Startup has begun by invoking it’s ‘StartListening’ event.
• Start up the DisplayDriver, and as soon as possible. Use ‘Start’ method.
• Register GUI to be notified by DisplayDriver’s ReadyForUse event, and KeyboardListener’s KeyPressed events
• When GUI starts, …

Oh, for goodness sake, why didn’t I choose an easier example! Ahem. The rest is left as an exercise.

Note, however, that the description is a bullet-list, rather than a numbered list. The dependencies are described, and the order of clauses does not matter.

For an application server to go from configuration files/data to an instantiated set of objects, the application server needs to be able to create objects based on an external description, that the compiler does not know about at compile time, and may change without re-compilation (for example, depending on a class name stored in a text file)

Here is the point Java naturally overtakes C++: it is dynamic enough to act like an interpreted (as opposed to compiled) language when in needs to be, and has class loaders which can take a string at run-time, and create an instantiation of the relevant class name.

C++ Programmers can already see ways around this, but also know it may be tricky to make this ultimately flexible, and will sigh with jealousy at the ease of Java in this respect.

Help is at hand though!

Why bother?

To add IOC to the systems-programming mix is an art.

It doesn’t solve anything in itself.

It is another spin on Component Based Development (CBD)… ever heard of vendors trying to flog graphical systems for assembling systems from ‘business components’, for use by business-people? Well, that will not happen for many reasons, some of them psychological, some of them practical (basically, it takes all kinds to make a world).

However, CBD can bring the technologists, ops-people and business-people to almost a common language, and can partition a solution implementation into bits the business want to know about, and bits they’d prefer not to know about…and that is at a much higher declarative level than a non-IOC world.

However, selecting which bits to ‘componentise’, and what configuration and methods to expose to an IOC world is an art, and requires business input.