Inversion of Control Using Generics - Revisiting the Separation of Use and Implementation
Martin Fowler in his famous article "Inversion of Control Containers and the Dependency Injection pattern" has compiled a number of ways how to dynamically bind a client to a service. I now would like to add two points to the discussion: firstly a distinction regarding what is injected, and secondly a new pattern for injection based on generics. During my discusson I´ll use the same sample scenario as Martin to make it easy to see what I´m trying to add. Here´s a quick recap using C#.
Martin is talking about a client component or class called a MovieLister which is supposed to filter a list of movies to find the ones directed by a particular director:
class MovieLister
{
IMovieFinder finder;
…
public Movie[] MoviesDirectedBy(string directorName)
{
List<Movie> resultset = new List<Movie>();
foreach (Movie m in finder.FindAll())
if (m.Director == directorName)
resultset.Add(m);
return resultset.ToArray();
}
}
class Movie
{
…
public string Director { get { … } }
}
Now, this client class is depending on a service managing all the movies and getting a list of them. To the client this service is only known through an interface, though – IMovieFinder –, to decouple it from any concrete implementations:
interface IMovieFinder
{
List<Movie> FindAll();
}
The question Martin´s article revolves around is: How does the MovieLister get at an instance of IMovieFinder? Obviously it´s no option to just instanciate, say, a class MovieFinder, which might implement the interface IMovieFinder in MovieLister´s constructor. That would make MovieLister dependent on a particular implementation of the interface and is exactly what´s to be avoided to keep the MovieLister class easily testable.
Martin´s answer consists of a number of patterns of how to inject an instance of a IMovieFinder implementation into the MovieLister. I won´t repeat them here in detail but rather just show a code snippet to bring them into the world of C#. For explanations see Martin´s article.
Constructor Injection
Pass in an instance of IMovieFinder when creating a MovieLister:
class MovieLister
{
public MovieLister(IMovieFinder finder)
{
this.finder = finder;
}
…
Setter Injection
Set the finder of a MovieLister object at any time through a property or setter method:
class MovieLister
{
public IMovieFinder Finder
{
set
{
this.finder = value;
}
}
…
Interface Injection
Separate the injection method into an interface of its own:
interface IInjectMovieFinder
{
void InjectFinder(IMovieFinder finder);
}
class MovieLister : IInjectMovieFinder
{
public void InjectFinder(IMovieFinder finder)
{
this.finder = finder;
}
…
Service Locator
Ask a service locator object or class to provide an instance:
static class ServiceLocator
{
public static IMovieFinder GetMovieFinder()
…
}
}
class MovieLister
{
public MovieLister()
{
this.finder = ServiceLocator.GetMovieFinder();
}
…
Type Injection or Instance Injection
As valuable as these patterns are, I found their discussion somewhat incomplete, since it lacks a distinction. Martin´s article seems to be talking only about instances of a service described by an interface. But in fact it´s not that simple.
True, the injection patterns push an instance of an interface implementation into the client object. But what does the service locator do? It enables the client to create an instance of a service at any time. Essentially that´s the same functionality the new operator provides. A service locator is a factory, and thus it´s just an indirection for instanciating a type.
That very fact I think should be made clear when talking about dependency injection and inversion of control. There are two kinds of it: injecting instances and injecting types. Injecting an instance is useful whereever a client just needs one instance of an unknown implementation type. Injecting a type, though, is useful whereever a client needs to be able to create instances of an unknown implementation type at will.
Service locator is just one pattern for “injecting” a service type into a client, i.e. making a client independent of concrete implemenations. Types also can be injected through other means; the instance injection patterns described by Martin can be used for type injection, too. Here´s just one example, constructor type injection:
class MovieLister
{
public MovieLister(Type movieFinderType)
{
this.finder = (IMovieFinder)Activator.CreateInstance(movieFinderType);
}
…
Instead of passing an instance to the constructor, just the type implementing IMovieFinder is injected. The client then can use the .NET Activator class to instanciate any number of objects of IMovieFinder implemenation. The client can even call CreateInstance() with parameters to be passed on to the constructor of the otherwise unkown type.
Setter type injection and interface type injection work accordingly. Just pass in a type instead of an instance of that type. However, there´s a drawback to this kind of type injection: it´s not type-safe. You can pass in any type, not just implementations of IMovieFinder. There´s no compiletime check against it. Fortunately, help´s on its way…
Generics Type Injection or Type Parameter Injection
Now for a type injection specific pattern: generic type injection or type parameter injection.
When you think of constructors as a means to pass objects to an instance during creation, then you can think of generics as a means to pass types to an instance during creation. That suggests using them for type injection:
class MovieLister<IMovieFinderClass>
where IMovieFinderClass : IMovieFinder, new()
{
private IMovieFinder finder;
public MovieLister()
{
this.finder = new IMovieFinderClass();
}
…
Passing a type to an instance by using a generics type parameters solves the problem of the unspecific Type used in the previous type injection example. You can constrain the generics type parameter to match a number of criteria. For example the above MovieLister forces any types injected to really implement the IMovieFinder interface and also provide a default constructor. Any instanciation of a MovieLister not matching these criteria will be flagged at compiletime!
Conclusion
When talking about separating use, specification and implemenation, I mostly use some kind of service locator to “inject” types at runtime into my components. That way of dynamically binding implementations to me simply is close to the way how I would program, would I knew the exact implementation types at development time. But since I just know their specifications (interfaces), I ask the service locator to look up a matching implementation.
However, when developing a standalone component for use in multiple, possible yet unknown contexts, I don´t always want to burden it with a service locator framework. The user of the component would need not only to learn my component, but also the service locator framework I chose. In those cases I like to use one of the true injection patterns. And recently I came to like very much generics type injection, because it´s type-safe and allows the client code to instanciate any number of service objects.