Simple Factory with parameter condition, using Unity 2.0

Question

Let's say I have a Simple Factory (SimpleProductFactory) that uses a condition parameter to determine how to create Products like this:

public static class SimpleProductFactory
{
    public static Product MakeProduct(Condition condition)
    {
        Product product;
        switch(condition)
        {
            case Condition.caseA:
                product = new ProductA();
                // Other product setup code
                break;
            case Condition.caseA2:
                product = new ProductA();
                // Yet other product setup code
                break;
            case Condition.caseB:
                product = new ProductB();
                // Other product setup code
                break;
        }
        return product;
    }
}

This factory is used by some client that handles runtime data containing the condition like this:

public class SomeClient
{
    // ...
    public void HandleRuntimeData(RuntimeData runtimeData)
    {
        Product product = SimpleProductFactory.MakeProduct(runtimeData.Condition);
        // use product...
    }
    // ...
}

public class RuntimeData
{
    public Condition Condition { get; set; }
    // ...
}

How can I achieve the same construction behavior using Unity 2.0?
The important part is that the condition (Condition) determines how to create and setup the Product, and that the condition is only known at runtime and differs for each MakeProduct(...) call. (The "Other product setup code" deals with some delegate stuff, but could also be handling other initializations, and needs to be part of the construction.)

How should the container registration of Product (or an IProduct inteface) be done?
Should I use an InjectionFactory construction? How do I do that?

// How do I do this?
container.RegisterType<Product>(???)

What do I need to do to be able to supply the condition in the client code?

Naïve client code (from a previous edit) to highlight the last question, that explains the wordings of a couple of the answers:

public class SomeClient
{
    // ...
    public void HandleRuntimeData(RuntimeData runtimeData)
    {
        // I would like to do something like this,
        // where the runtimeData.Condition determines the product setup.
        // (Note that using the container like this isn't DI...)
        Product product = container.Resolve<Product>(runtimeData.Condition);
        // use product...
    }
    // ...
}

_{(I have read through a lot of similar questions here at Stackoverflow but haven't been able to fit them, and their answers, to my needs.)}

Solution 1

You should not use the container to make runtime decisions like this. Instead, inject your factory into the client via the container. If the factory needs dependecies from the container, inject them into the factory at creation time.

Change your factory to an actual object instead of just being a container for static methods, and inject that.

Solution 2

You should not inject or use the container in your classes in any way. This includes the use of parameters. The reason for this is that doing so will bind your code to the container. You will then be left with a lot of work if you ever have to implement another container or even a new version.

However for the case your describing Unity (and some other injection frameworks) has a feature that is called 'automatic factory'. It uses the .NET Func<TResult> delegate. This is a .NET feature so it doesn't tie your class to Unity.

This is how to use it, first register your service. Do not register it with a ContainerControlledLifetimeManager or you will get the same instance every time.

unity.RegisterType<IOpenFileService, OpenFileService>();

Then register an automatic factory for it.

unity.RegisterType<Func<IOpenFileService>>();

This can then be injected in any class that needs it.

unity.RegisterType<ViewModelBase, OptionsFileLocationsViewModel>(
    new InjectionConstructor(new ResolvedParameter<Func<IOpenFileService>>());

If you now resolve an instance of OptionsFileLocationsViewModel it will not be injected with an instance of IOpenFileService but with a function that if called will return an instance of IOpenFileService.

private readonly Func<IOpenFileService> openFileServiceFactory;

private string SelectFile(string initialDirectory)
{
    var openFileService = this.openFileServiceFactory();
    if (Directory.Exists(initialDirectory))
    {
        openFileService.InitialDirectory = initialDirectory;
    }
    else
    {
        openFileService.InitialDirectory =
            System.Environment.GetFolderPath(System.Environment.SpecialFolder.Desktop);
    }

    bool? result = openFileService.ShowDialog();
    if (result.HasValue && result.Value)
    {
        return openFileService.FileName;
    }

    return null;
}

I hope this brief explanation of mine will inspire you to solve your issue.

Solution 3

you may do define unique names for your registrations;

container.RegisterType<Product ,ProductA>("ProductA");
container.RegisterType<Product, ProductB>("ProductB");

or in configuration file;

<register type="Product" mapTo="ProductA" name="ProductA" />
<register type="Product" mapTo="ProductB" name="ProductB" />

then you may resolve the instance based on the registration:

string productName = "ProductB";
Product product = container.Resolve<Product>(productName);

You may also use a class like the following for names;

public class ProductTypes
{
    public static string ProductA
    {
        get
        {
            return "ProductA";
        }
    }

    public static string ProductB
    {
        get
        {
            return "ProductB";
        }
    }
}

then;

container.RegisterType<Product,ProductA>(ProductTypes.ProductA);
container.RegisterType<Product,ProductB>(ProductTypes.ProductB);

and resolve it;

Product product = null;

switch(condition)
{
    case Condition.caseA:
        product = container.Resolve<Product>(ProductTypes.ProductA);
        // Other product setup code
        break;
    case Condition.caseA2:
        product = container.Resolve<Product>(ProductTypes.ProductA2);
        // Yet other product setup code
        break;
    case Condition.caseB:
        product = container.Resolve<Product>(ProductTypes.ProductB);
        // Other product setup code
        break;
}

return product;

Solution 4

As @ChrisTavares describes, and as is described in this answer, the solution is to simply inject the factory into the client SomeClient. Further, in order to follow the Dependency Inversion Principle (DIP), the client should depend only on an abstract factory such as the factory interface IProductFactory.

It's actually just a question of doing plain Dependency Injection (DI). The use of Unity is merely as a DI facilitator to handle the resolving of the (constructor) dependencies. Only the concrete factory ProductFactory needs to be registered with the unity container. The creation of products is fully handled by the factory, where it's perfectly okay to use the 'new' keyword.

container.RegisterType<IProductFactory, ProductFactory>();

Here is what a solution could look like:

public interface IProductFactory
{
    IProduct MakeProduct(Condition condition);
}

internal class ProductFactory : IProductFactory
{
    public IProduct MakeProduct(Condition condition)
    {
        IProduct product;
        switch (condition)
        {
            case Condition.CaseA:
                product = new ProductA();
                // Other product setup code
                break;
            case Condition.CaseA2:
                product = new ProductA();
                // Yet other product setup code
                break;
            case Condition.CaseB:
                product = new ProductB();
                // Other product setup code
                break;
            default:
                throw new Exception(string.Format("Condition {0} ...", condition));
        }
        return product;
    }
}

public class SomeClient
{
    private readonly IProductFactory _productFactory;

    public SomeClient(IProductFactory productFactory) // <-- The factory is injected here!
    {
        _productFactory = productFactory;
    }

    // ...
    public void HandleRuntimeData(RuntimeData runtimeData)
    {
        IProduct product = _productFactory.MakeProduct(runtimeData.Condition);
        // use product...
    }
    // ...
}

public class RuntimeData
{
    public Condition Condition { get; set; }
    // ...
}

public interface IProduct
{ //...
}
internal class ProductB : IProduct
{ //...
}
internal class ProductA : IProduct
{ //...
}
public enum Condition { CaseA, CaseA2, CaseB }

View more solutions

Comments

[Ulf Åkerstedt]

Thanks. Yes, but then I'm missing the additional logic of the factory, and also I would need to map the RuntimeData.Condition to class names in the client! I don't want the client to know other than the condition to get a product based on that.

[crush]

Encapsulate the product setup code inside of the product with a common interface...product.setup(); then you can eliminate entire switch

[daryal]

@UlfÅkerstedt maybe I did not understand the question properly; but my answer provides the same behavaiour with your current code; please provide your whole code so I can understand the question easily.

[Ulf Åkerstedt]

Yes, using the container such as in the SomeClient class of my question is not DI but rather Service Locator.

[dmigo]

What should such a Factory look like? Should it just use Container inside?