Jay Kimble

This is about the worst implementation (wanna be implementation) of DI I have ever seen.

You are making a huge assumption that you will only ever need to inject 1 dependancy. WRONG.

On the up side, you just invented a new form of DI called Generic Injection. Now we have 3 types of injection (constructor, setter and generic).

I would not suggest you use this pattern in real life.

Without being as beligerant as Mr. Whittaker here, I'll talk about a few issues with ragards to this kidn of pattern.

First, it's usally the case that when something varies only by type, that's a sign that type templating (generics) should come into play. But there are some caveats in this particular case, which I'll get to in a bit.

Second, DI and IoC are nothing new and don't exist solely in the realm of testing. These concepts were invented long before automated unit testing became the new hip thing. If you look at a lot of software out there that have interchangeable implementations, this is actually the norm. Take the .NET crypto framework as an example. When you call DES.Create(), it's using a factory implementation to create a specific implementation of the DES algorithm (or any other cipher, take your pick, depending on the base class). That way, your application isn't stuck using a single implementation, and the Ops guys can even swap it out in production with a simple config change (the concrete type is specified in machine.config i believe).

However, when you create an entire framework where every (or nearly every) dependency is uncoupled and replaceable, you need some plumbing to do the type resolution of the hundres or thousands of dependency instantiations you might have. That plumbing will either take a giant config or allow the program to dynamically specify the type resolutions.

And this is where the generics approach kinda fizzles. At some point, someone is going to have to specify a concrete T. But if the app doesn't know that T is going to be until runtime, you can't really do that without resorting to hokey reflection, so it's sort of a moot point, and wouldn't offer any more than non-generics approaches that are already out there.

Is it possible to post an update to this article and make it highly visible. While I don't want to be too hard on you, this is really spreading some misinformation and bad practices.

Tim

Jay,

It isn't dependency *injection* unless you push the dependency in from the outside, which is what the pattern arrives at when doing TDD and needing to verify that the dependency was used correctly based on the logic in the class that uses the dependency.

Constructing dependencies an the using class's constructor is what dependency injection seeks to avoid. T _dependency is a dependency is a dependency, but it's an opaque dependency that can't be replaced at runtime with a fake or a simulator for testing purposes.

Let's say that T _dependency is a funds transfer service. It's easier when writing logic for the using class to use a fake funds transfer service than a real funds transfer service.

You could use configuration to swap the funds transfer service with a fake, but then you'd have to twiddle configuration between logic unit testing and end to end testing. It's simple and more direct to open up the dependency in the using class's constructor:

public MyClass(T dependency)
{
_dependency = dependency
}

In test code, you simply construct the class using the dependency that is appropriate to the kind of test:

new MyClass(new FakeDependency)

An IoC tool automates object construction by inspecting constructor arguments and providing the instances of the dependencies that are already in the IoC container:

container.AddDependencyType(typeof(FundsTransferService))

So constructing the using class is never more difficult than:

MyClass myObject = container.Build<MyClass>();

If FundsTransferService had dependencies exposed through its constructor args, and those dependencies had dependencies exposed through their constructor args, and so on, construction of MyClass would always be the same:

MyClass myObject = container.Build<MyClass>();

As long as the container is fed the System.Type of all of the dependency objects, constructing any class with dependencies is always a simple matter of asking the container for an instance of some object where the entire chain of exposed dependencies is populated.

So, test code becomes much simpler, dependencies are explicitly documented via constructor args, and production code (or production testing code) benefits from the intelligence of the IoC container and the dependency types that have been added to it.

Inversion of Control (IoC) simple means something like, "push dependencies in from the outside," and an Inversion of Control container (or "framework"), is just an automation tool for doing this stuff in production.

@Derik: Ouch! Take it easy on Jay, he's learning-out-loud which can lead to mistakes (publicly). This is a teachable moment :)

@Jay: I would not call this Dependency Injection per se. Well, at least not for MyNewClass. MyNewClass has a static dependency on ClassThatImplementsISomeInterface and there's no injection going on and therefore would not be as testable.

However, MyClassWithADependency<T> does have a measure of dependency injection (or rather, dependency transparency, it's not really being injected).

This assumes that there is logic in the MyClassWithADepdencny<T> that needs tested (and if not, why does MyClassWithADependency<T> exist in the first place ;) )

You could do a PartialMock of MyClassWithADependency<T> using Rhino Mocks and use a Test Double implementation of ISomeInterface to set up your interaction testing.

However, you really haven't made your life any easier by doing this. It depends what the problem is and what other options are or are not available to you to solve it.

Generally, I would not recommend this approach and, instead, prefer Constructor and possibly Setter/Property injection. It's just easier!

@Jay: Or.... what Scott said :)

Jay,

I came back to better explain myself and my thoughts because it dawned on me that my comments were not helpful, but others have done a great job of explaining the failings of this post.

Sorry for the 'mean spirited' comment.

I agree with Jay. Experimenting is good and helps you learn. It is not only important to know the does but most certainly the don'ts. And not taking everything for granted is the only way to evolve as a person and as a professional.

Anyway most reactions were very positive and nobody died.

Astonishing reactions.

I think your mistake may have been to suggest this was a Dependency Injection strategy, not simply a strategy for injecting a dependency. It's those Capital Letter terms that cause the angry posts.

Because clearly, the originally stated MyClassWithADependency<T> class does provide a mechanism for specifying at the point the class is used what implementation of a particular dependency it should employ.

Alright, so it's not as flexible as it might be. It requires the injected class to support parameterless construction. It accomplishes little that's not already accomplished by simply writing this (constructor-injectable) class:

public class MyClassWithADependency : SomeBaseClass
{
ISomeInterface _dependency;
public MyClassWithADependency(ISomeInterface dependency)
{
_dependency = dependency;

}
}

This version requires the calling code to supply the dependency (or allows an IoC container to do it), which lets you relax the parameterless constructor restriction. But they're not hugely different.

Jay's generic class simply enforces a policy about who's responsible for instantiating the dependency (that might be desirable in some circumstances, since it's clear who's going to clean it up), and also exposes the implementing dependency type as part of the runtime type of the object - which also might be useful in some circumstances.

For goodness' sake, it's just a generic class with a constraint on it; the point is valid that such a class can be used to externalise the choice of a dependency implementation from the implementation of the dependent class. Not everything has to use an IoC container, not everything has to use an approved Dependency Injection pattern.

It's just a way of moving implementation decisions and dependencies around your codebase. It's all good. Chill.

James,

Since the varying of the dependency can only be done at compile time, why make it so abstractly-variable. The result is inevitably static rather than variable. It's only variable in source code. What value does this approach bring that pays for the tradoff that comes from making things perhaps unnecessarily abstract?