How to refactor an application with multiple switch cases

design-patternsobject-oriented-design

I have an application which takes an integer as input and based on the input calls static methods of different classes. Every time a new number is added, we need to add another case and call a different static method of a different class. There are now 50 cases in the switch and every time I need to add another case, I shudder. Is there a better way to do this.

I did some thinking and came up with this idea. I use the strategy pattern. Instead of having a switch case, I have a map of strategy objects with the key being the input integer. Once the method is invoked, it will look up the object and call the generic method for the object. This way I can avoid using the switch case construct.

What do you think?

Best Answer

There are now 50 cases in the switch and every time I need to add another case, I shudder.

I love polymorphism. I love SOLID. I love pure object oriented programming. I hate to see these given a bad rep because they get applied dogmatically.

You have not made a good case for refactoring to strategy. The refactoring has a name by the way. It's called Replace Conditional with Polymorphism.

I've found some pertinent advice for you from c2.com:

It really only makes sense if the same or very similar conditional tests are repeated often. For simple, seldom-repeated tests, replacing a simple conditional with the verbosity of multiple class definitions, and likely moving all this far from the code that actually requires the conditionally required activity, would result in a textbook example of code obfuscation. Prefer clarity over dogmatic purity. -- DanMuller

You have a switch with 50 cases and your alternative is to produce 50 objects. Oh and 50 lines of object construction code. This is not progress. Why not? Because this refactoring does nothing to reduce the number from 50. You use this refactoring when you find you need to create another switch statement on the same input somewhere else. That's when this refactoring helps because it turns 100 back into 50.

So long as you're referring to "the switch" like it's the only one you have, I don't recommend this. The only advantage to come from refactoring now is that it reduces the chances that some goofball will copy and paste your 50 case switch.

What I do recommend is looking closely at these 50 cases for commonalities that can be factored out. I mean 50? Really? You sure you need that many cases? You might be trying to do to much here.

Related Solutions

C# – Pass the whole object to a method or just parts

I have an object that has about 50 properties,

Stop! Go - right now - and fix this.

Of course you're going to run into functions that only use part of your object, when your object is doing everything under the sun. No object needs 50 independent properties. Certainly some of them can be organized into sub-objects. Those three that your function takes are a good candidate set.

should I pass the whole object to a function or just parts?

In the more general case, it depends. Best practices say to pass in just what you need. Best practices also say to code to an interface (in this case, the signature of the method). So this is one of those cases where you need to weigh the two best practices against the likelihood that they will come into play.

Does the method make sense to take the whole thing (since you might use other parts later)? Does the method make sense to the parts and not care that they are from independent sources?

And the other consideration is similar to the above advice: if you often find yourself taking bits from an object, it is a sign that those bits are their own cohesive object. Consider making them their own sub-object, or otherwise divvying up responsibilities to better align with how you're actually using the stuff.

Also, this answer is specifically about functions. If you're working across communication boundaries, you will often want to/need to cut down your data size. Sending 50 fields across the wire when you only need 3 is more troublesome there.

Clean Code – How to Reduce a Switch in a Switch Statement

Add the title to the parameters of the printf:

char* title1;
switch(gender1){
    case 'M':
        title1 = "Sir";
        break;
    case 'W':
       title1 = "Madam";
        break;
    case ...etc.
}
char* title2;
switch(gender2){
    case 'M':
        title2 = "Sir";
        break;
    case 'W':
       title2 = "Madam";
        break;
    case ...etc.
}
printf("Dear %s %s and %s %s", title1, name1, title2, name2);

you can extract the switch to its own function for re-usability and compactness.

Best Answer

Related Solutions

C# – Pass the whole object to a method or just parts

Clean Code – How to Reduce a Switch in a Switch Statement

Related Topic