Working with Abstract Factory that is injected through DI container

Question

I`m confused about Dependency Injection implementation in one concrete example.

Let's say we have a SomeClass class that has a dependency of type IClassX.

public class SomeClass
{
     public SomeClass(IClassX dependency){...}
}

Creation of concrete implementations of IClassX interface depends on runtime parameter N.

With given constructor, I can't configure DI container(Unity is used), because I don't know what implementation of IClassX will be used in runtime. Mark Seemann in his book Dependency Injection In .Net suggests that we should use Abstract Factory as an injection parameter.

Now we have SomeAbstractFactory that returns implementations of IClassX based on runtime paramater runTimeParam.

public class SomeAbstractFactory
{
     public SomeAbstractFactory(){ }

     public IClassX GetStrategyFor(int runTimeParam)
     {
         switch(runTimeParam)
         {
             case 1: return new ClassX1();
             case 2: return new ClassX2();
               default : return new ClassDefault();
         }
     }
}

SomeClass now accepts ISomeAbstractFactory as an injection parameter:

public class SomeClass
{
     public SomeClass(ISomeAbstractFactory someAbstractfactory){...}
}

And that's fine. We have only one composition root where we create the object graph. We configure Unity container to inject SomeAbstractFactory to SomeClass.

But, let's assume that classes ClassX1 and ClassX2 have their own dependencies:

public class ClassX1 : IClassX
{
    public ClassX1(IClassA, IClassB) {...}
}

public class ClassX2 : IClassX
{
    public ClassX2(IClassA, IClassC, IClassD) {...}
}

How to resolve IClassA, IClassB, IClassC and IClassD dependencies?

1. Injection through SomeAbstractFactory constructor

We can inject concrete implementations of IClassA, IClassB, IClassC and IClassD to SomeAbstractFactory like this:

public class SomeAbstractFactory
{
     public SomeAbstractFactory(IClassA classA, IClassB classB, IClassC classC, IClassD classD)
     {...}
     ...
}

Unity container would be used in the initial composition root and then use poor man’s DI to return concrete ClassX1 or ClassX2 based on parameter runTimeParam

public class SomeAbstractFactory
{
     public SomeAbstractFactory(IClassA classA, IClassB classB, IClassC classC, IClassD classD){...}

     public IClassX GetStrategyFor(int runTimeParam)
     {
         switch(runTimeParam)
         {
             case 1: return new ClassX1(classA, classB);
             case 2: return new ClassX2(classA, classC, classD);
               default : return new ClassDefault();
         }
     }
}

Problems with this approach:

• SomeAbstractFactory knows about dependencies that don`t really belong to it.
• Deeper object graph would require to change both SomeAbstractFactory constructor and class implementation
• DI container would not be used to resolve dependencies, poor man`s DI must be used

2. Explicit call to DI container

Instead of “newing up” ClassX1 or ClassX2, we would resolve them by using a DI container.

public class SomeAbstractFactory
{
     public SomeAbstractFactory(IUnityContainer container){...}

     public IClassX GetStrategyFor(int runTimeParam)
     {
         switch(runTimeParam)
         {
             case 1: return container.Resolve<IClassX>("x1");
             case 2: return container.Resolve<IClassX>("x2");
               default : return container.Resolve<IClassX>("xdefault");
         }
     }
}

Problems with this approach:

• DI container is passed into SomeAbstractFactory
• DI Resolve method is not used only at the composition root (ServiceLocator anti-pattern)

Is there another more suitable approach?

Answer 1

The example below shows how to do this with Unity. This blog post explains it a little better using Windsor. The underlying concept is exactly the same for each, just slightly different implementation.

I would rather allow my abstract factory to access the container. I view the abstract factory as a way to prevent dependency on the container - my class only depends on IFactory, so it's only the implementation of the factory that uses the container. Castle Windsor goes a step further - you define the interface for the factory but Windsor provides the actual implementation. But it's a good sign that the same approach works in both cases and you don't have to change the factory interface.

In the approach below, what's necessary is that the class depending on the factory passes some argument that allows the factory to determine which instance to create. The factory is going to convert that to a string, and the container will match it with a named instance. This approach works with both Unity and Windsor.

Doing it this way the class depending on IFactory doesn't know that the factory is using a string value to find the correct type. In the Windsor example a class passes an Address object to the factory, and the factory uses that object to determine which address validator to use based on the address's country. No other class but the factory "knows" how the correct type is selected. That means that if you switch to a different container the only thing you have to change is the implementation of IFactory. Nothing that depends on IFactory has to change.

Here's sample code using Unity:

public interface IThingINeed
{}

public class ThingA : IThingINeed { }
public class ThingB : IThingINeed { }
public class ThingC : IThingINeed { }

public interface IThingINeedFactory
{
    IThingINeed Create(ThingTypes thingType);
    void Release(IThingINeed created);
}

public class ThingINeedFactory : IThingINeedFactory
{
    private readonly IUnityContainer _container;

    public ThingINeedFactory(IUnityContainer container)
    {
        _container = container;
    }

    public IThingINeed Create(ThingTypes thingType)
    {
        string dependencyName = "Thing" + thingType;
        if(_container.IsRegistered<IThingINeed>(dependencyName))
        {
            return _container.Resolve<IThingINeed>(dependencyName);
        }
        return _container.Resolve<IThingINeed>();
    }

    public void Release(IThingINeed created)
    {
        _container.Teardown(created);
    }
}

public class NeedsThing
{
    private readonly IThingINeedFactory _factory;

    public NeedsThing(IThingINeedFactory factory)
    {
        _factory = factory;
    }

    public string PerformSomeFunction(ThingTypes valueThatDeterminesTypeOfThing)
    {
        var thingINeed = _factory.Create(valueThatDeterminesTypeOfThing);
        try
        {
            //This is just for demonstration purposes. The method
            //returns the name of the type created by the factory
            //so you can tell that the factory worked.                
            return thingINeed.GetType().Name;
        }
        finally
        {
            _factory.Release(thingINeed);
        }
    }
}

public enum ThingTypes
{
    A, B, C, D
}

public class ContainerConfiguration
{
    public void Configure(IUnityContainer container)
    {
        container.RegisterType<IThingINeedFactory,ThingINeedFactory>(new InjectionConstructor(container));
        container.RegisterType<IThingINeed, ThingA>("ThingA");
        container.RegisterType<IThingINeed, ThingB>("ThingB");
        container.RegisterType<IThingINeed, ThingC>("ThingC");
        container.RegisterType<IThingINeed, ThingC>();
    }
}

Here's some unit tests. They show that the factory returns the correct type of IThingINeed after inspecting what was passed to its Create() function.

In this case (which may or may not be applicable) I also specified one type as a default. If nothing is registered with the container that exactly matches the requirement then it could return that default. That default could also be a null instance with no behavior. But all of that selection is in the factory and container configuration.

[TestClass]
public class UnitTest1
{
    private IUnityContainer _container;

    [TestInitialize]
    public void InitializeTest()
    {
       _container = new UnityContainer();
       var configurer = new ContainerConfiguration();
       configurer.Configure(_container);
    }

    [TestCleanup]
    public void CleanupTest()
    {
        _container.Dispose();
    }

    [TestMethod]
    public void ThingINeedFactory_CreatesExpectedType()
    {
        var factory = _container.Resolve<IThingINeedFactory>();
        var needsThing = new NeedsThing(factory);
        var output = needsThing.PerformSomeFunction(ThingTypes.B);
        Assert.AreEqual(output, typeof(ThingB).Name);
    }

    [TestMethod]
    public void ThingINeedFactory_CreatesDefaultyTpe()
    {
        var factory = _container.Resolve<IThingINeedFactory>();
        var needsThing = new NeedsThing(factory);
        var output = needsThing.PerformSomeFunction(ThingTypes.D);
        Assert.AreEqual(output, typeof(ThingC).Name);
    }
}

This same factory can be implemented using Windsor, and the factory in the Windsor example could be done in Unity.