Is there a good way to use polymorphism to remove this switch statement?

Question

I've been reading on refactoring and replacing conditional statements with polymorphism. The trouble I have is that it only seems to make sense to me when you have a more complex case where, without polymorphism, you would have to repeat the same switch statements or if-elses many times. I don't see how it makes sense if you're only doing it once - you have to have that conditional somewhere, right?

As an example, I recently wrote the following class, which is responsible for reading a XML file and converting its data into the program's objects. There are 2 possible formats for the file that we are supporting, so I simply wrote a method in the class for handling each one, and used a case-switch to determine which one to use:

public class ComponentXmlReader
{
    public IEnumerable<UserComponent> ImportComponentsFromXml(string path)
    {
        var xmlFile = XElement.Load(path);
        switch (xmlFile.Name.LocalName)
        {
            case "CaseDefinition":
                return ImportComponentsFromA(xmlFile);
            case "Root":
                return ImportComponentsFromB(xmlFile);
        }
    }

    private IEnumerable<UserComponent> ImportComponentsFromA(XContainer file)
    {
        //do stuff
    }

    private IEnumerable<UserComponent> ImportComponentsFromB(XContainer file)
    {
        //do stuff
    } 
}

As far as I can tell, I could write a class hierarchy for this to do the parsing, but I don't see the advantage here - I'd still have to use a case-switch to determine which class to instantiate. It looks to me like it would be extra complexity for no benefit. If I was going to keep these classes around and do more things with them that depended on the file type, then it would eliminate doing the same switch in multiple places, but this is single-use. Is this right, or is there some reason or technique I'm not seeing that makes it a good idea to use a polymorphic class hierarchy to do this?

Answer 1

As with all design choices, context is key. In this case, you have what seems to be a fairly simple class handling two very similar tasks. If the two Import methods contained very little duplicate code, then including them in a single class is perhaps the best choice since, as you say, it reduces complexity.

However, it's possible you'll use this class in the future, and even add new types of imports. In that case, the class would be more reusable if it was polymorphic.

Additionally, since these methods sound very similar, you're likely to have a bunch of duplicate code, which you could keep in a base class and only put import-specific code in the child classes.

Plus, as Carl mentions, there are numbers of ways to implement this logic without using a case statement.

Answer 2

If you had, say, an abstract ComponentImporter class, with concrete subclasses FromA and FromB, you could instantiate one of each, and put it in a Map. Then you could call componentImporterMap.get(xmlFile.Name.LocalName).importComponents() and avoid the switch.