IOC 0.29

IOC Perl module is a lightweight IOC (Inversion of Control) framework.

SYNOPSIS

use IOC;

my $container = IOC::Container->new();
$container->register(IOC::Service::Literal->new(log_file => "logfile.log"));
$container->register(IOC::Service->new(logger => sub {
my $c = shift;
return FileLogger->new($c->get(log_file));
}));
$container->register(IOC::Service->new(application => sub {
my $c = shift;
my $app = Application->new();
$app->logger($c->get(logger));
return $app;
}));

$container->get(application)->run();

This module provide a lightweight IOC or Inversion of Control framework. Inversion of Control, sometimes called Dependency Injection, is a component management style which aims to clean up component configuration and provide a cleaner, more flexible means of configuring a large application.

What is Inversion of Control

My favorite 10 second description of Inversion of Control is, "Inversion of Control is the inverse of Garbage Collection". This comes from Howard Lewis Ship, the creator of the HiveMind IoC Java framework. His point is that the way garbage collection takes care of the destruction of your objects, Inversion of Control takes care of the creation of your objects. However, this does not really explain why IoC is useful, for that you will have to read on.

You may be familiar with a similar style of component management called a Service Locator, in which a global Service Locator object holds instances of components which can be retrieved by key. The common style is to create and configure each component instance and add it into the Service Locator. The main drawback to this approach is the aligning of the dependencies of each component prior to inserting the component into the Service Locator. If your dependency requirements change, then your initialization code must change to accommodate. This can get quite complex when you need to re-arrange initialization ordering and such. The Inversion of Control style alleviates this problem by taking a different approach.

With Inversion of Control, you configure a set of individual Service objects, which know how to initialize their particular components. If these components have dependencies, the will resolve them through the IOC framework itself. This results in a loosely coupled configuration which places no expectation upon initialization order. If your dependency requirements change, you need only adjust your Services initialization routine, the ordering will adapt on its own.