Case Statements for string to string mapping

Question

I have a class called SomethingProvider that contains:

private static string convertMapA(string convertA)
    {
        switch (convertA?.ToUpper())
        {
            case "NONE":
            case "TEST":
            case "MEHTEST":
                return "None";
            case "MEH":
                return "meh";
            case "DAY":
            case "SOMEDAY":
                return "da";
            case "CON":
            case "C":
                return "cd";
            default:
                return convertA;
        }
    }

    private static string convertMapB(string convertB)
    {
        switch (convertB?.ToUpper())
        {
            case "ANNY":
            case "ANYU":
            case "BLAH":
                return "something";
            default:
                return convertB;
        }
    }

There can be multiple versions of this class, I.e ClassAlphaProvider, ClassBetaProvider. Each method Convert will have slightly different mappings dependent on its class.

And to make it more interesting there are multiple Projects, with multiple classes, with these convertMapping methods that alter per class.

Now, I was considering, dictionary mapping instead or, implement strategy pattern but feels overkill for strings mapping? Maybe even Db implementation of sorts?

What would be a good approach to refactoring this?

NOTE: the case statements change frequently. trying to consider open/close with the idea that the case statements change a lot.

the data is all been changed to dummy data along with method and class names so ignore the toUpper stuff hehe — lemunk, Feb 22 '22 at 11:53
I get that, but posting code samples which blatantly don't function isn't helpful for people attempting to understand the problem; your second code sample won't even compile. — Philip Kendall, Feb 22 '22 at 11:54
As mentioned the code detail isnt super relevant, there are methods with case statments specific to mapping strings, muliple classes have the same methods with slighly different mappings etc, muliple projects etc. Hence why i posted on here and not stackoverflow, this is more of a "what would you do to refactor this?" not specific code implimentation else i would have used stack overflow — lemunk, Feb 22 '22 at 11:57
How is this code being used? Are you mapping database values? Do the mapped values affect application behavior? I'm afraid there isn't enough information to answer your question. — Greg Burghardt, Feb 22 '22 at 13:27
Well, some of the detail might be relevant. E.g. based on the information provided so far, there might be no compelling reason to refactor. Now, you did say "the case statements change frequently", but what else does that imply? If these changes only affect the internals of these `convertMapX` methods, than that might not be worth refactoring, but something tells me that's not the case. So, what else is affected? Do the signatures of these methods change? Do you have to add new methods? Do you have to change the calling code. Does some code rely on the string values returned, and if so, how? — Filip Milovanović, Feb 22 '22 at 13:29
For example, are there if statements elsewhere in the codebase that check the values of the mapped versions of these strings in order to make a decision. Are there "parallel" if statements at different places. Things like that — Filip Milovanović, Feb 22 '22 at 13:34

score 0 · Answer 1 · answered Feb 22 '22 at 13:29

Switch statements for mapping aren't terrible. Switch statements for string to string mapping sounds like there is a hidden enum/record type that should exist instead. If you have multiple different mappings for different objects across multiple different projects, that is fine. If you have multiple different mappings for functionally the same object, that is bad. In the latter case you are better off consolidating to a single library and sharing it across projects, it's better to have the hard link that can be tracked than no link.

score 0 · Answer 2 · answered Feb 22 '22 at 16:34

It sounds like these mappings are not really part of the functionality of your code but application configuration data. If they change frequently and don't influence the code path but just determine some output strings I would really recommend putting them into some configuration datastore or a database table. That makes maintenance much more flexible.

If the mappings can have common and individual parts depending on class and project, the configuration data structure probably needs to be a bit more complex, with generic mappings and overrides (and probably override precedence rules when you have multiple dimensions in which the mappings can be specialized, such as the named projects and classes).

It is also quite possible that you've got an XY problem here, and it would be helpful to know the real use case for these mappings instead of some abstract "meh"/"blah"/"something".

Case Statements for string to string mapping

2 Answers2