A "Function lookup table" in place of switches

Question

I came across some code recently that replaces the use of switches by hard-coding a

Dictionary<string (or whatever we would've been switching on), Func<...>> 

and where ever the switch would've been, it instead does dict["value"].Invoke(...). The code feels wrong in some way, but at the same time, the methods do look a bit cleaner, especially when there's many possible cases. I can't give any rationale as to why this is good or bad design so I was hoping someone could give some reasons to support/condemn this kind of code. Is there a gain in performance? Loss of clarity?

Example:

public class A {
    ...
    public int SomeMethod(string arg){
        ...
        switch(arg) {
            case "a": do stuff; break;
            case "b": do other stuff; break;
            etc.
        }
        ...
    }
    ...
}

becomes

public class A {

    Dictionary<string, Func<int>> funcs = new Dictionary<string, Func<int>> {
        { "a", () => 0; },
        { "b", () => DoOtherStuff(); }
        ... etc.
    };

    public int SomeMethod(string arg){
        ...
        funcs[arg].Invoke();
        ...
    }
    ...
}

Answer 1

Advantages:

1. You can change the behaviour at runtime of the "switch" at runtime
2. it doesn't clutter the methods using it
3. you can have non-literal cases (ie. case a + b == 3) with much less hassle

Disadvantages:

1. All of your methods must have the same signature.
2. You have a change of scope, you can't use variables defined in the scope of the method unless you capture them in the lambda, you'll have to take care of redefining all lambdas should you add a variable at some point
3. you'll have to deal with non-existant indexes specifically (similar to default in a switch)
4. the stacktrace will be more complicated if an unhandled exception should bubble up, resulting in a harder to debug application

Should you use it? It really depends. You'll have to define the dictionary at some place, so the code will be cluttered by it somewhere. You'll have to decide for yourself. If you need to switch behaviour at runtime, the dictionary solution really sticks out, especially, if the methods you use don't have sideeffects (ie. don't need access to scoped variables).

Answer 2

For several reasons:

1. Because doing it this way allows you to select what each case branch will do at runtime. Otherwise, you have to compile it in.
2. What's more, you can also change the number of branches at runtime.
3. The code looks much cleaner especially with a large number of branches, as you mention.

Why does this solution feel wrong to you? If the dictionary is populated at compile time, then you certainly don't lose any safety (the delegates that go in certainly have to compile without error). You do lose a little performance, but:

1. In most cases the performance loss is a non-issue
2. The flexibility you gain is enormous