Before diving into our solution, let's look a little deeper into the meaning of Inversion of Control.

Inversion of Control is a paradigm where we alter the way we create objects. In simple object creation scenarios, if we have modules X and Y, and X needs an instance of Y, we would let X directly create it. This introduces a direct dependency between X and Y, as shown in the following diagram.

It's dependent because any changes to Y may impact X and incur required updates. This dependency isn't just between X and Y. X is now dependent on Y and all of Y's dependencies (as shown below). Any updates to Y or any of its dependencies run the risk of impacting X.

With Inversion of Control, we break this potential risk of impacts from Y and its dependencies to X by delegating creation of instances of Y to a separate container, as shown below.

This shifts the dependency between X and Y over to the container, reducing the coupling.

We saw in our wiki engine code how WikiService was dependent on MySqlDataAccess. MySqlDataAccess is dependent on MySQLdb, a python library for communicating with MySQL. Using the container and coding against a well defined interface opens up the opportunity to change what version of data access is being injected into WikiService.

As we continue our example in the next section, we'll see how IoC can help us make management of test code easier, reducing long term maintenance costs.

We already took the first step in reducing maintenance costs by eliminating our dependency on MySQL by using a test stub. However the mechanism we used incurred a great risk due to violation of the DRY (Don't Repeat Yourself) principle.

For our current problem, we want Spring Python to manage the creation of WikiService in a way that allows us to make changes in one place, so we don't have to edit every test method. To do this, we will define an IoC container and let it handle creating the objects for us. The following code shows a simple container definition.

With this change, we are now getting WikiService from the container, and then overriding it with the StubDataAccess. You may wonder "what was the point of that?" The key point is that we shifted creation of our testable wiki_service object to the container. To complete the transition, we need to remove all dependency of MySqlDataAccess from WikiService. Before we do that, let's discuss Dependency Injection.

So far, we have managed to delegate creation of our WikiService object to Spring Python's Inversion of Control container. However, WikiService still has a hard-coded dependency to MySqlDataAccess.

The nature of IoC is to push object creation into a 3rd party location. Up to this point, we have been using the term Inversion of Control. The way that Spring Python implements IoC, is through the mechanism of Dependency Injection. Dependency Injection, or DI, is where dependencies are pushed into objects through either initialization code or by letting the container directly assign attributes. This is sometimes described by the Hollywood cliché of Don't call us, we'll call you. It means that the object which needs a certain dependency shouldn't make it directly, but instead wait on the external container to provide it when needed.

The following version of WikiService shows a complete removal of dependence on MySqlDataAccess.

class WikiService(object):
def __init__(self, data_access):
self.data_access = data_access
def statistics(self, page_name):
"""Return tuple containing (num hits, hits per edit)"""
hits = self.data_access.hits(page_name)
return (hits, hits / len(self.data_access.edits(page_name)))

With this altered version of WikiService, it is now up to WikiService's creator to provide the concrete instance of data_access. The corresponding change to make to our IoC container looks like this.

from springpython.config import PythonConfig
from springpython.config import Object
class WikiProductionAppConfig(PythonConfig):
def __init__(self):
super(WikiProductionAppConfig, self).__init__()
@Object
def data_access(self):
return MySqlDataAccess()
@Object
def wiki_service(self):
return WikiService(self.data_access())

We have added a definition for MySqlDataAccess so that we can inject this into the instance of WikiService when it's created. Our dependency diagram now shows a complete break of dependency between WikiService and MySqlDataAccess.

As described earlier, this is akin to the Hollywood mantra Don't call us, we'll call you. It opens up our code to the possibility of having any variation injected, giving us greater flexibility, without having to rewrite other parts of the system.

With this adjustment to WikiService and WikiProductionAppConfig, we can now code an alternative way of setting up our test case.

The dependencies (or lack of!) between WikiService and StubDataAccess are shown in following diagram:

This makes it easy to plug in our alternative StubDataAccess. An important thing to note is how our test code is no longer overriding the data_access attribute, or doing any other special steps when creating WikiService. Instead, this creation logic has been totally turned over to the IoC container. We can now easily write as many tests as we want with no risk of changes to WikiService or data_access, provided we continue to rely on the IoC container to handle object creation. We just visit the blueprints of WikiTestAppConfig to make any future alterations.

In conclusion of this example, the following diagram shows our current objects as well as potential enhancement to our system. In this possible situation, we have defined multiple data access components. To find out which one is being injected into WikiService, we simply look at the relevant container's definition, whether its production or a particular test scenario. Our current system may use MySQL, but if a new customer wanted to use PostGreSQL, we simply create another variation of our container, and inject the alternate data access object. The same can be said for Sqlite. And all of this can be done with no impact to WikiService.