Factory pattern implementation

Question

I need to create one of a number of different objects based on some value and I was advised to look into the Factory patterns. I do not want my client having to decide which object to create or to require hard-coded class names, so after doing some reading I came up with the following (simplified) example:

public class ObjectA : IObject 
{
}

public class ObjectA : IObject 
{
}

public interface IObjectFactory
{
    IObject CreateObject(ObjectCreationParameters p);
}

public abstract ObjectFactory : IObjectFactory
{
    abstract IObject CreateObject(ObjectCreationParameters p);
}

public ConcreteObjectFactory : ObjectFactory
{
    public IObject CreateObject(ObjectCreationParameters p)
    {
        IObject obj;
        switch (p.Value)
        {
            case A:
              obj = new ObjectA();
              break;
            case A:
              obj = new ObjectB()
              break;
        }
        return obj;
    }
}

The above works but I am a little confused as to whether my implementation is correct or not.

I would prefer not to have an ObjectAFactory and an ObjectBFactory as in a Factory Method pattern if it can be avoided, however, my object hierarchy does not seem to follow the same object hierarchy as in example of the Abstract Factory pattern. I do not have an ObjectA2 or ObjectB2 that would ever be created via a ConcreteObject2Factory.

Is my implementation correct or am I doing something wrong and if so, what?

The purpose of a factory is to not let calling code worry about how to create the object. The caller should not need to specify what class he wants instantiated. — usr, Nov 30 '13 at 21:23
you need to check the difference between factory method pattern and abstract factory pattern. this link has a good explanation http://stackoverflow.com/questions/4209791/design-patterns-abstract-factory-vs-factory-method — mamdouh alramadan, Dec 01 '13 at 02:29

score 0 · Answer 1 · answered Nov 30 '13 at 21:24

0

What you really want to look at is Inversion of Control (IoC); that is essentially the factory pattern but taken to its natural conclusion.

Simply put you register all of your types with an IoC container and then delegate the task of creating them over to that. In a nice modern application you infrequently create objects (and almost never explicitly) and you never wory about their dependencies, it all gets done for you.

In C# my favourite IoC container is Autofac I've been using it for quite a while in a rowing project and it pretty much just keeps on doing what it needs to do. There are others, but I'd say it is a good place to start.

answered Nov 30 '13 at 21:24

satnhak

9,407
5
63
81

I failed to mention the values used to create the objects will be determined at run-time. Does the affect your suggestion for using an IoC container? – Peppermintology Nov 30 '13 at 23:55
No, you can specify some or all of the constructor parameters at run time using an IoC container (https://code.google.com/p/autofac/wiki/DelegateFactories). – satnhak Dec 02 '13 at 10:36

Konrad Kokosa · Accepted Answer · 2013-11-30T21:35:52.343

Yes, it is a correct implementation. This switch statement may seem to be problematic and non-polymorphic but in fact, you can read about it in an excellent Code Clean book, rule G23: Prefer Polymorphism to If/Else or Switch/Case:

“ONE SWITCH” rule: There may be no more than one switch statement for a given type of selection. The cases in that switch statement must create polymorphic objects that take the place of other such switch statements in the rest of the system.

Your implementation abstracts creation of concrete object, co client don't have to worry about it and that is what this design pattern is for. Look also, for example, at Encapsulation section in the Wikipedia entry.

Factory pattern implementation

2 Answers2