In Part 1 of this short series, we outlined the basic behavior for the simplest possible DI container; what I’ll call Kontainer.

In this segment, we will write some code to make those tests pass. In order to allow us to make those tests pass, I wound up doing the following:

• Keep a list of definitions that are registered with the container
• Abstract the idea of an object definition
• Abstract the idea of a creation policy such that singleton and prototype are instantiations of a creation policy, but we could add other creation policies externally if we want.

This led to the following basic code:

The basic class to hold the definition:

The policy used to govern the creation of the objects in the user provided Function

A slightly modified version of the registry part of the container

and the basic bits of the core container

In order to test sub-property resolution, I also added the following test:

What is that all about? Well, the Function signature takes an argument for the calling container so that the class being built can resolve its own dependencies via the container.

This code was sufficient to make our basic round of tests pass. In addition, it was a little bit of relatively simple code. Furthermore, we can handle other creation policies aside from singleton and prototype. In order to prove that out, I added the following test:

 And the other test creation policy:

This is a ’singleton per thread creation policy’. This creation policy allows there to be a singleton created per thread. It uses primative locking style that we may change when we make the ‘whole shebang’ thread safe. Essentially – this will allow us to just prove out that we can supply alternate creation policies.

In the next part – we will sort our the disposal needs…

Responses are currently closed, but you can trackback from your own site.