Advice on "Factory" Pattern Implementation

Passing a query string, or any string really, to the factory is troubling.

Why I avoid strings:

1. typos
2. CasEinG
3. Presumed encoding/structure can be problematic.

IMHO the ideal will be to pass a parameter to the factory that unambiguously tells what to construct. As is, the factory is making gross assumptions about the content & validity of the incoming query string. But there is no telling what free-form text is in it.

The client code should evaluate & validate the query string and then pass the appropriate thing to the factory. And IMHO do not pass a string. Use enums. enums are:

1. type safe
2. avoid typos
3. self documenting - all the possible class-types are defined here.
4. Query string validation - now that we have a definitive list of all possible class-types we can verify the query string contents against the enum
5. intelisense in visual studio

Design thoughts

1. Below is not the Abstract Factory Pattern per se. We are not creating factories of factories. The point of a factory is to separate "complex construction (code)" from the using class. The more complex the constructions "the more factory we need".
2. Simple? then a static (or not) method w/in the client class is ok.
3. Longish & somewhat complex? a separate class.
4. Use the Factory in many places? a separate class might be best.
5. Many variations of each class-type? Perhaps a full-blown abstract factory design. etc., etc, and etc.
6. IMHO, making the Factory class an instance, static, or singleton is your call.

The Dictionary Examples

1. Other examples using a dictionary are interesting. I'd use an enum for the key, not strings. overall it feels like the reflection/abstraction aspects are wasted as it's all internal and you still have to "open the factory", i.e. modify it, to add/delete class-types.
2. The dictionary is necessary only because we pass the entire query string to the factory. Again, Tell the factory what to build don't make it try to guess (see above about "gross assumptions"). The calling client is the absolute best place with the proper context to decide what to build.
3. Making the factory parse the query string - and therefore handle problems - is violating the single responsibility principle.

.

internal public class Factory{
    public AbstractClass Create(abstracts makeThis) {
        AbstractClass newClass;

        switch(makeThis) {
           case abstracts.class1:
              newClass = BuildClass1();
              break;

           case abstracts.class2:
              newClass = BuildClass2();
              break;
           // and so on.

           default:
              throw new NotImplementedException();
              break;
        }
        return newClass;
    }

    // build methods here.
}

public enum abstracts {class1, class2, class3}

public class Client{
    AbstractClass factoryBuiltThing;
    Factory classFactory = new Factory();

    // put some error handling in here
    protected bool ParseQueryString(string queryString, out buildThis) {}

    // put some error handing here too.
    protected abstracts DeriveAbstractEnum(string theDesiredClass){};

    public void BuildSomething(string queryString) {
        string buildThis = string.Empty;
        abstracts whatToBuild;

        if (ParseQueryString (queryString, out buildThis)) {
            whatToBuild = DeriveAbstractEnum(buildThis);
            factoryBuiltThing = classFactory.Create(whatToBuild);
         }else { 
            throw new NotImplementedException(
                string.format("The query string is crap: {0}", queryString));
         }
    }

}