Re: [boost] Proposal for Library to perform dependency injection

Subject: Re: [boost] Proposal for Library to perform dependency injection
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2009-10-27 03:52:43

Adam Young wrote:
> Having had a career that has bounced me between a few languages, I
> have had the opportunity to work with a couple of tools in the Java
> world that didn't see, to have analogues in C++.  One of these is the
> inversion of control containers, of which Spring is one of the best
> known.  Ken Fowler suggested the term "Dependency Injection" as a way
> to better describe how inversion of control is performed, and I
> prefer his term.
>
> I've written a fairly simple dependency injection framework in C++
> that seems to make proper use of the C++ Language.  It is not
> attempting to do any COM like component model.  Rather, it allows the
> developer the ability to cleanly separate the Object usage from the
> construction policy.
>
> I've posted the code on Sourceforge at
> https://sourceforge.net/projects/cpp-resolver/.  I have not yet taken
> the time to get it into proper format for a Sandbox project, but will
> do that next if there seems to be enough interest in the project.  I
> wrote up the philosophy behind the design here:
>
> http://adam.younglogic.com/?p=146
>
> The code is currently g++ only, although I've attempted to use only
> core language constructs.  It has no dependencies on other libraries
> other than stl collections.
>
> Any constructive feed back will be most appreciated.

I've been using "manual" DI (mostly constructor-based injection) for a long 
time in C++, and would be interested in a generic DI framework. If it could 
be made to work with dynamically loaded classes it would be even better - 
perhaps with a little help from the proposed Boost.Plugin library that was 
under development some time ago.

That being said, you'll need to provide some more documentation in order for 
at least me to have any specific comments. Starting out with some more 
snippets and examples would be a great idea, IMHO.

Some desired functionality off the top of my head:

- Simple registration, preferably in some declarative (instead of 
imperative) way.
- Allow e.g. manual, thread-specific, stack-based (see below as well) and 
global registration. Consumers should not need to be aware of which one they 
are using.
- It should be possible to specify fallback/priority policies; e.g. 
stack-based -> thread-specific -> global.
- Support for temporarily overriding resolvers; e.g. scoped_resolver<T, 
...>. Allows for easier test case development, among other things.
- Support for injecting specific instances as well as types/factories.

Regards,
Johan Nilsson