Question

I parse/process data coming from many different streams (with different formats) and the number of different sources for data keeps growing in my system. I have a factory class which based on a config file specifying the source will give me the appropriate parser/processor pair (abiding to a small common interface) requested in something like this:

static Foo* FooFactory::createFoo(source c, /*couple flags*/)
{
    switch (c)
    {
        case SOURCE_A:
        {
         //3 or 4 lines to put together a parser for A, and something to process stuff    from the parser
             return new FooA(/*args*/);
        }
        break;
        //too many more cases which has started to worry me
        default:
            return NULL;
    };
}

the problem is as the number of sources has grown I am facing two issues. First, when I build, I find myself pulling in all the FooA, FooB, FooC, FooD, FooE... relevant code – even if I was only interested in perhaps building a binary in which I’ll only request FooA lets say. So how to go about modularizing that. A secondary issue is, right now in the case of SOURCE_A, I am returning FooA, but what if I am interested in SOURCE_A but I have different ways of parsing it and perhaps I want FooA_simple and FooA_careful but with the ability to plug and play as well?

For some reason, one thing that came to mind was the -u option to the linker when building a binary…it somehow suggests to me the notion of plug and play but I’m not sure what a good approach to the problem would be.

Answer 1

Well, you just create a factory interface and divide the logic among subtypes of that factory. So there might be a sub-factory (type/instance) for libFooA, and another for libFooB. Then you can simply create a composite factory depending on the subfactories/libraries you want to support in a particular scenario/program. Then you could even further subdivide the factories. You could also create factory enumerators for your composite types and do away with all that switch logic. Then you might say to your libFooA factory instance to enable careful mode or simple mode at that higher level. So your graph of FooFactory instances and subtypes could easily vary, and the class structure could be like a tree. Libraries are one way to approach it to minimize dependencies, but there may be more logical ways to divide the specialized sub-factories.