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 Service's initialization routine, the ordering will adapt on it's own.

For links to how other people have explained Inversion of Control, see the "SEE ALSO" section.

Why Do I Need This?

Inversion of Control is not for everyone and really is most useful in larger applications. But if you are still wondering if this is for you, then here are a few questions you can ask yourself.

Do you have more than a few Singletons in your code?

If so, you are a likely candidate for IOC. Singletons can be very useful tools, but when they are overused, they quickly start to take on all the same problems of global variables that they were meant to solve. With the IOC framework, you can reduce several singletons down to one, the IOC::Registry singleton, and allow for more fine grained control over their life-cycles.

Is your initialization code overly complex?

One of the great parts about IOC is that all initialization of dependencies will get resolved through the IOC framework itself. This allows your application to dynamically reconfigure it load order without you having to recode anything but the actual dependency change.

Are you using some kind of Service Locator?

My whole reasoning for creating this module was that I was using a Service Locator object from which I dispensed all my components. This created a lot of delicate initialization code which would frequently be caused issues, and since the Service Locator was initialized after all the services were, it was necessary to resolve dependencies between components manually.

Inversion of Control in detail

The authors of the PicoContainer IoC framework defined 3 types of Dependency Injection; Constructor Injection, Setter Injection and Interface Injection. This framework provides the the ability to do all three types within the default classes using a pseudo-type, which I call Block Injection (for lack of a better term). This framework allows a service to be defined by an anonymous subroutine, which gives a large degree of flexibility. However, we also directly support both constructor injection and setter injection as well. Interface injection support is on the to-do list, but I feel that interface injection is better suited to more 'type-strict' languages like Java or C# and is really not appropriate to perl.

There are a number of benefits and drawbacks to each approach, I will now attempt to list them.

Constructor Injection

Constructor injection tends to encourages what are called Good Citizen Objects, which are objects who are fully initialized once they are constructed. It is also easy to analyze dependency relationships since the components are stored in the constructor parameters.

One drawback to this approach is that it requires the component to be a class, as well as requires the class to be a Good Citizen. Which is okay if you are writing the class, but maybe not when it is a 3rd party class.

Setter Injection

Setter injection has its benefits as well. Since all object initialization is done through setter methods, it allows for a cleaner object design when there are a lot of dependencies. Where in a constructor injection, it would cause an explosion of parameters in the constructor. Setter injection dependencies can also be easily analyzed programmatically, since the dependencies are stored in the setter parameters.

However, as with constructor injection, some of the the benefits can also be drawbacks. Sometimes having public setters for initialization is not what you would want normally in your class.

IOC-style Block Injection

This style is, in my opinion the most perl-ish approach. It is also, arguably, the simplest approach since it requires very little on the part of the component class, and easily allows for non-object services. It can be used to mix both constructor and setter injection in the same service object.

One major drawback is that since the initialization is "hidden" within the anonymous subroutine, it is very difficult to programatically analyze the dependency relationships.

To give credit where credit is due, this style is not my own invention, but instead was derived from an IoC Ruby implementation in the article mentioned in the "SEE ALSO" section.

Is this module ready to use?

Yes, I have been using this actively in production for a couple years now, and it has worked without issue.

Configuration Classes

IOC::Config::XML

This module allows you to configure an IOC::Registry object using XML.

Container Classes

Containers classes can hold references to both IOC::Service objects as well as other IOC::Containers. Containers are central to the framework as they provide the means of managing, storing and retrieving IOC::Service objects.

IOC::Container

This is the base Container object. In most cases, this class will be all you need.

IOC::Container::MethodResolution

This is a subclass of IOC::Container, and adds the ability to retrieve services and sub-containers with a method call syntax, instead of passing a string key to a retrieval method.

Service Classes

Service classes are the even more central to the framework since they are what hold and dispense the dependency objects. There are a number of types of service class, all of which are derived at some point from the base IOC::Service class.

IOC::Service

This is the base Service object. In most cases, this class will be all you need.

IOC::Service::ConstructorInjection

This extends the IOC::Service object to allow for a constructor injection style.

IOC::Service::SetterInjection

This extends the IOC::Service object to allow for a setter injection style.

IOC::Service::Parameterized

This extends the IOC::Service object to allow for additional parameters to be passed during service creation. Since there is an unbound parameter, these services will work like the prototyped services and return a new instance each time.

Prototyped Services

Most services are singletons, meaning there is only one instance of each service in the system. However, sometimes this is not what you would want, and sometimes you want to set up a prototypical instance of a component and get a new instance each time. This set of Service classes provide just such functionality.

NOTE: This is not really the same as prototype-based OO programming, we do not actually create a prototypical instance, but instead we just call the creation routine each time the component is requested.

IOC::Service::Prototype

A basic prototype-style Service class.

IOC::Service::Prototype::ConstructorInjection

This extends the IOC::Service::Prototype object to allow for a constructor injection style.

IOC::Service::Prototype::SetterInjection

This extends the IOC::Service::Prototype object to allow for a setter injection style.

Visitor Classes

IOC::Visitor classes are used by other classes in the system to perform various search and traversal functions over a IOC::Container hierarchy. They are mostly for internal use.

IOC::Visitor::ServiceLocator

Given a path, this will attempt to locate a service within a IOC::Container hierarchy.

IOC::Visitor::SearchForService

Given a service name, this will attempt to locate a service within a IOC::Container hierarchy by doing a depth first pre-order search.

IOC::Visitor::SearchForContainer

Given a container name, this will attempt to locate a service within a IOC::Container hierarchy by doing a depth first pre-order search.

Utility Classes

These classes are really just support classes for the framework.

IOC::Exceptions

Defines a number of exceptions (with Class::Throwable) used in the system.

IOC::Interfaces

Defines a number of interfaces (with Class::Interfaces) used in the system.

Wishlist

These are things which I have in the back of my head and would someday like to create, but just don't have the time right now.

Dependency Analyzer

I would like to create some kind of Visitor object which would traverse a IOC::Container hierarchy and analyze the dependencies in it. This is somewhat simple for the ::ConstructorInjection and ::SetterInjection Services since they store the keys to their dependencies inside the object. However it is more complex with regular IOC::Service objects which utilize the Block Injection pseudo-type. For those the initialization block would need to probably be run through B::Deparse and the dependency code parsed out.

Dependency Visualization

I hacked out a quick script which created a GraphViz .dot file which visualized the dependency tree. It left much to be desired, but it served as a proof of concept. I would like to expand that idea into a more useful and flexible tool. If anyone is interested in doing this one, contact me and I will send you the proof of concept script.