Inversion of Control – Why is It Named That Way?

IoC (see Inversion of Control on Wikipedia) is applicable in cases where a component can not perform a task entirely because it doesn't have some necessary information or functionality.

The simplest example of an IoC pattern would be callback functions in C. For example you can declare the function:

void Iterator(void *list, Func* f)

Which iterates over list applying the f function to each of it's item. The Iterator function doesn't know how each item will be processed, you just provide a function as an argument, and it processes them.

As the previous example shows, IoC allows you to decouple your program into separate components that don't know about each other. One of the most common versions of IoC is Dependecy Injection.

In Dependency Injection each component must declare a list of dependencies required to perform it's task. At runtime a special component (generally) called an IoC Container performs binding between these components. It tries to provide values for published component dependencies.

Here is an example in pseudo-code:

class Foo 
{ 
   <Require Boo>Constructor(Boo boo){ boo.DoSomething } 
}

In this example class Foo has a constructor that requires argument of type Boo to perform some action.

You could create an instance of class Foo using code similar to this:

MyContainer.Create(typeof Foo)

MyContainer - is an IoC Container, which takes care of getting instance of Boo and passing it to the Foo constructor.

In summary, IoC allows you to decouple your program into separate parts. This is good because:

• Components can be easily tested independently.
• Program complexity can be reduced.
• You can switch components to another implementation.

However in some cases, IoC can make code harder to understand.

If you want to see good example of real-world usage of IoC, have a look at Mircosoft Composite UI Application Block and CompositeWPF

I hope my explanation helps you.

Regards,
aku

Definitions

Inversion of control is a design paradigm with the goal of reducing awareness of concrete implementations from application framework code and giving more control to the domain specific components of your application. In a traditional top down designed system, the logical flow of the application and dependency awareness flows from the top components, the ones designed first, to the ones designed last. As such, inversion of control is an almost literal reversal of the control and dependency awareness in an application.

Dependency injection is a pattern used to create instances of classes that other classes rely on without knowing at compile time which implementation will be used to provide that functionality.

Working Together

Inversion of control can utilize dependency injection because a mechanism is needed in order to create the components providing the specific functionality. Other options exist and are used, e.g. activators, factory methods, etc., but frameworks don't need to reference those utility classes when framework classes can accept the dependency(ies) they need instead.

Examples

One example of these concepts at work is the plug-in framework in Reflector. The plug-ins have a great deal of control of the system even though the application didn't know anything about the plug-ins at compile time. A single method is called on each of those plug-ins, Initialize if memory serves, which passes control over to the plug-in. The framework doesn't know what they will do, it just lets them do it. Control has been taken from the main application and given to the component doing the specific work; inversion of control.

The application framework allows access to its functionality through a variety of service providers. A plug-in is given references to the service providers when it is created. These dependencies allow the plug-in to add its own menu items, change how files are displayed, display its own information in the appropriate panels, etc. Since the dependencies are passed by interface, the implementations can change and the changes will not break the code as long as the contract remains intact.

At the time, a factory method was used to create the plug-ins using configuration information, reflection and the Activator object (in .NET at least). Today, there are tools, MEF for one, that allow for a wider range of options when injecting dependencies including the ability for an application framework to accept a list of plugins as a dependency.

Summary

While these concepts can be used and provide benefits independently, together they allow for much more flexible, reusable, and testable code to be written. As such, they are important concepts in designing object oriented solutions.