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.

It is no secret to people who know me that am a HUGE DI proponent. When using a language like C# or Java certainly – you must do it to maintain a degree of flexibility, separation and manageability in their software.

I have used most of the DI containers. Last- I wrote one @ home over the weekend and brought it in to my last employer. In this series of posts – I am going to write a simple DI container, then go and make it threadsafe using some of Jeff Richter’s ’stuff’.

So how do I want this simple container to be?

• JUST DI, (not broad like Spring)
• Code based (no xml)
• Label based (not just type based)
• As little code as possible

Why those things??

Just DI 

I want it really, really simple. I have explained DI to people for some time and it is often obfuscated by whatever tool we are using. My ‘dumb simple’ explaination is usually something like:

When you are writing a class, and you need some other thing to help you carry out your behavior, in stead of newing it alive, depend on the appropriate abstraction and allow it to be injected. What do I mean by injected? I mean make a constructor arg or allow a settable property

Code based

I just want code – no XML, etc. It is a pain to debug etc.

Label based (below)

As little code as possible

I want AS LITTLE CODE AS POSSIBLE. I want to maintain NO CODE.

Constructor args or settable properties

Well – constructor args give you a ‘guaranteed fully baked class’ (as long as your arguments are ‘valid’ eg; not null, in the proper state, range etc). Changing constructor args can sometimes be a pain. They are also less amenable to odd circular dependencies (admittedly to be avoided anyhow). While I appreciate the value of constructor args – my general experience is that sometimes settable properties are more flexable. Take for example the case where you need to inject dependencies POST construction (in WinForms for example often the designer will ‘new’ your types).

Type based injection or label based injection?

Some friends of mine prefer type based injection. Some of the other current containers prefer type injection as well. Essentially the idea is that you ‘bind’ some abstraction to some single concrete implementation. For example:

// registration
diContainer.Bind(typeof(FooImpl))

// usage
IFoo f = diContainer.Resolve()

What I don’t like about this is that it forces you to have 1 implementation of IFoo in the system. This is OK in many cases, but it fights the ability to have N different implementations of a common interface. Take for example IPresenter or IView or something general like this. Binding a single implementation to something like this is prohibitive.

So – I prefer to have label based lookups. This has its own downside, mainly that you have to look for string names. With string based lookup – it is something like:


// registration
diContainer.Register("A", typeof(FooImpl)) // or some variation


// usage
IFoo f = diContainer.Resolve("A")


.. or something like that. The salient bit is the fact that you are asking for something by name, as opposed to just by type.

So I am comfortable using settable properties sometimes and names/ labels because:

• With tests, you can be a bit more dynamic
• It is generally a bit more flexable IMO
• With autoproperties, it is little code

So – what do I want the simple container to do?

• Allow me to register definitions for singletons using lambdas/ delegates
• Allow me to register definitions for prototypes (factory behavior)using lambdas/ delegates
• Allow me to register singletons that are already created
• Allow me to inject properties on instances of objects that already exist
• Allow me to get objects from the container by name
• Allow me to dispose objects when the container disposes
• Allow me to dispose objects when the container disposes
• Allow me to add behaviors externally via some hook points

Here are the basic starter tests then of Kontainer, my simple container:

With this set of tests, we get the following interfaces:

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

Well, here are some pics (we took ~1000 pics, this is a small ‘best of’ selection).

We went to:

• Saratoga (near Cupertino, Mountain View, etc.) to visit some friends that moved from NY (their lovely daughters are the ones with our boys in the photos – their best friends).
• Yosemite
• San Francisco

We stayed with our friends in their lovely place in Saratoga. We then stayed in Oakhurst (too far from Yosemite – but we reserved TOO LATE for a good hotel). I DO NOT recommend, the Oakhurst lodge – but at least it was clean and had a small fridge in the room. In San Fran we stayed at the Hotel Nikko – which I DO recommend – it was great.

=Chris=

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