My main concern called out in this article is that the majority of switch statements I’ve run into in production code involve multiple switches with multiple responsibilities and invariably would be better off in polymorphic form.

In these cases, your dictionary refactor is an effective addition to the steps called out in this article (in the case where creation of the appropriate subclass needs handled by a switch), but the main problem in the code isn’t the existence of a switch but the use of it.

The main point of “Refactorring a switch statement was that a switch statement can be replaced with a Dictionary. Even if the switch is done correctly (with polymorphism), like you did here, can still contain a rather nasty switch statement in the guts.

For example: If you are writing a tag processor (you are taking in a file with custom, distinct, tags in that that indicated a need to perform an action), the list of possible tags can get quite large. One commenter on my post was talking about having 1500 case statements in a single switch because of this.

Everything was kept simple in that post to highlight one point: a Dictionary is an effective alternative. Even all the suggestions that people put on the blog ignored one fact: they had done everything but remove the switch. I wanted it GONE.

You moved the switch to another class, which had merely migrated an ugly piece of code to a new home — which is what you are supposed to do with code that is becoming unmanageable, but I wanted to make it less ugly from the start. No polymorphic trick will remove a switch statement (but it will make it easier to remove).

Part of this could just be me. I don’t hate the switch statement, I use them from time to time, but I think they should be used much more rarely than they are.

But, effective refactoring is a multi-step process. Thank you for showing one of the other steps.