Abstract Factory Experiment

Question

While I should probably be using Dependency Injection via Ninject or a similar project, I have been attempting to implement an abstract factory design that would provide me with the following easy to read and use syntax:

UniversalFactory.Factory<IFoo>.Create<FooImpl>(... parameters ...);

I'm throwing this experiment on here in order to solicit some constructive feedback both with implementation logic and design reasoning.

Here is my current implementation:

public class UniversalFactory
{
    private readonly IFactory<IFoo> FooFactoryEx;

    public UniversalFactory()
    {
        FooFactoryEx = new FooFactory();
    }

    public IFactory<T> Factory<T>()
    {
        if (typeof (T) == typeof (IFoo))
            return (IFactory<T>)FooFactoryEx;
        return null;
    }
}

public interface IFactory<in TF>
{
    T Create<T>(params object[] p) where T : TF;
}

public class FooFactory : IFactory<IFoo>
{
    public T Create<T>(params object[] p) where T : IFoo
    {
        if (typeof(T) == typeof(FooImpl))
        {
            var id = Convert.ToInt32(p[0]);
            return (T)FooImpl.Create(id);
        }
        return default(T);
    }
}

public interface IFoo
{
    // Some interface
}

public class FooImpl : IFoo
{
    public int Id { get; set; }

    private FooImpl(int id)
    {
        Id = id;
    }

    public static IFoo Create(int id)
    {
        var foo =  new FooImpl(id);
        return foo;
    }
}

This code allows a UniversalFactory to be instantiated and the following to be invoked successfully:

UniversalFactory.Factory<IFoo>().Create<FooImpl>(1);

My reasoning for this approach:

1. All construction is easily identifiable via the call to UniversalFactory.
2. Factories are invoked based on the interface implementation being constructed, hiding all details about the specific factory being used from the new object request.
3. The object type and its construction parameters are clearly identifiable in the request.
4. Object construction stays in each class, and any additional updates to other objects at construction time can take place in the factory method.

My current implementation has (at a minimum) the following flaws:

1. There is no compile-time safety that ensures IFoo is implemented by an IFactory. Only that FooImpl implements IFoo is ensured.
2. UniversalFactory.Factory has to add a check for every interface supported by a factory
3. Individual factories have to invoke static Create() methods within each class. It would be better if the static create could be invoked in a generic way, and Create(params object[] p) somehow mapped to Create(int a, string b, ...) as needed.

Thoughts? Feedback? Is this approach unnecessary or too complex? Hopefully this experiment is, at the least, interesting to a couple of other SO folk out there.

Answer 1

Well what you are trying to do is not strictly speaking an abstract factory. For it to be an abstract factory the use case should look like this:

UniversalFactory.Factory<IFoo>  // client has no idea about IFactory<IFoo> implementation
                .Create(... parameters ...); // client has no idea about IFoo implementation, returns IFoo

Ideally, you should not even need to pass parameters. That is why you are building factories after all. To delegate object creation.

Other minor remarks:

1. where T : TF - those are not very descriptive names for generic arguments. Perhaps you can come up with better naming.
2. var id = Convert.ToInt32(p[0]); - i'm not sure i like Convert here. It might hide bugs and misusages. I think that strong cast is better in that case.

3. public static IFoo Create(int id) - i don't see any reason to use factory method.

   public class FooImpl : IFoo
   {
       public int Id { get; private set; }
   
       public FooImpl(int id)
       {
           Id = id;
       }
   }
   

   this looks a lot cleaner. Also i think Id setter should be always private.

Overall, i think unless you are doing it for studying purposes, you should just grab an existing DI library, as you've metioned yourself :)

Answer 2

The code is really well written but that is a LOT of power to give one class. It has essentially created a dependency bottleneck.

Most of the advantages of factories is the ability to swap/change/update implementations without extraneous recompiling or changing.

Although here you are calling the Universal Factory (which as an implementation can't be changed without recompiling every class using it)

Second, you are calling the direct implementation in the call itself. this means that you are also dependent on that.

You correctly asserted the correct approach is probably a DI system. Alternatively you could stick with the factory and go with something like

IGlobalFactory factory;//Possibly constructor initialized

IFoo bar = factory.Create<IFoo>();

Whereby the GlobalFactoryImpl is Injected and provides a factory with implementation of your IFoo.

It is usually a bad idea to let your main class be aware there is a FooImpl in this way the GlobalFactoryImplcan return FooImpl when called but a GlobalFooBlargFactoryImpl can return a FooBlargImpl , you still get the ability to swap out implementation but everything is a little more obfuscated.