Polymorphic behaviour is the way to go in these situations (if possible). if..else..if..else* smells a lot more than switch statements, and performs like a dog at the same time - its a good indicator that you need to re-design your program.

On the point about switch statements, where performance is necessary, then they are the way to go - e.g. game or graphic engines, high-perf real time java, element identification when processing massive XML documents using a SAX parser etc.

The switch case construct and the foreach construct that another of the posters above disliked so much are used extensively by functional language proponents for a variety of tasks that make generally accepted design patterns redundant and seem more cumbersome once you get used to its strange looking syntax.

Remember that design patterns are not something sacred - they are simply common coding patterns to solve common problems - quite often these patterns are developed from within the context of the limitations of a language - it is a common misconception that design patterns are language agnostic - this is not true. Thankfully, this is not an original thought on my part - I have references to back me up, off the cuff here’s one.

As for the switch case itself - to see how it and its more advanced functional brother: pattern matching are used extensively and quite usefully you’ll need to look at functional language implementations - the topic is too complex for me to explain in a short reply here, suffice to say that once you get used to functional programming you’ll find yourself frustrated with non-functional programming languages. Since you’re obviously coming from a Java background I’d suggest you start with Scala - it takes a happy medium between OO and functional paradigms and even runs in the JVM and is interoperable with Java.

My earlier comment with Paul Graham’s fictitious “Blub” programming language was not in jest - I used to be where you are right now - not understanding why Java needed any changes and now I am on the other side and I understand why. There is a very fundamental reason why Java needs to change or die - it is the imminent software crisis that we are almost in in the midst of facing - multi-core programming. I admit it is a long shot, from switch-case statements to multi-core programming - but there is a connection - functional languages.

chain of responsibility. for instance jdbc: you don’t switch on the proper jdbc driver when you specify an url to the driver manager.

command pattern. for instance struts: you have a list of configured commands attached to a discriminator url. This avoid hard coding command triggers to switching on command implementations.

strategy: you have a list of algorithms that are injected in the executors, instead of having a switch in the executor to select the appropriate algorithm

observer: you have a set of classes that handle specific messages, instead of having a single class that switch on the messages to notify the appropriate listeners

If switch is perfect, it is quite strange that people invented so many patterns to avoid that (in different contexts, and for solving different problems).

I agree that sometime if-else-if-else are simpler than overcomplicated solutions. But most of the time doing a good design avoids switches and repeated ifs. My opinion is that is best to go for the easiest code.

“Blub falls right in the middle of the abstractness continuum… As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages… Blub is good enough for him, because he thinks in Blub.” — Paul Graham, Beating the Averages