Recently I was asked to throw a presentation together for my colleagues here at work. Among other things this presentation also explains what Inversion of control is and why implementing this pattern might be a good idea. The problem with the term 'Inversion of control' (IoC) is that a lot of people have different opinions on what this actually means and what it stands for. After surfing the Internet for a while and looking at several explanations found (mostly) in the Java community it became clear to me that it is not clear at all. But it basically boils down to this:

Inversion of control  =  A different way of how components are looked up and/or instantiated.

And that's it.
Given this definition it also becomes clear that IoC is not synonymous to Dependency Injection (Dependency injection is what Java's Spring and CF's ColdSpring framework for instance provide).
Instead, dependency injection is a form of inversion of control. But factory methods are also a form of IoC. And so is Dependency Lookup (also known as Service location).

As said, ColdSpring is the container that provides Dependency Injection (DI). DI basically comes in several flavours;

• Interface injection (aka Type 1 IoC)
• Setter injection (aka Type 2 IoC)
• Constructor injection ( aka Type 3 IoC)

ColdSpring (as well as Java's Spring) supports the setter- and the constructor injection mechanism's. In a nutshell it works like this:
Your component's init method (or a corresponding setter method) is injected automatically with the objects or properties it expects right after it has been created by ColdSpring and returned to you.

Suppose you have a component called 'doStuff' and you have another component that handles all your logging, called 'logger'. When creating an instance (createObject) of the DoStuff component, you need to provide it with the logging object so it can use it.

Withoud ColdSpring the code might look like this:

<cfset loggerInstance = createObject("component","logger")>
<cfset doStuffInstance = createObject("component","DoStuff").init(loggerInstance)>

Obviously, DoStuff's init method has a <cfargument> tag with a type = "logger">

with ColdSpring the code looks like this:

<cfset doStuffInstance = coldSpring.getBean("DoStuff")>

and DoStuff is automatically provided with the logger Object through the ColdSpring container. Great!

'Errmm.. HOLD ON!'  you might say, why go through the trouble of setting up ColdSpring and configuring the beans and all that stuff, just so I can type one line of code less?

AHA! but there are more important advantages:

• implementing IoC helps to reduce coupling.
• a central view for your dependencies. This significally reduces the sifting through component after component to figure out the dependency chain.
• reconfigure without changing  source code.
• leads to better testing.

Furthermore, ColdSpring also provides solutions for cross-cutting concerns like security and caching by means of using aspects inside the bean factory (AOP) but this falls a little outside the scope of this blogpost.