This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Just like the case labels needed to be compile time constants in "old" integer / enum switches, the case labels need to be compile time constants for String switches too. The problem is with view.getMessage().endsWith("Would you like to play again?"); that's a) not a compile time constant, and b) not a String.
What you can do is use a switch up to that "case", then use a default case for the remainder and an if-else-if-else inside that default case. It's either that, or keep the larger if-else-if-else block.
that's what i thought. i like the first idea since the if else is getting pretty ugly. too bad i have to check for view.getMessage().endsWith("Would you like to play again?") before the last two cases.
BTW i noticed that using Strings in switch statements is new to java 7
and everyone is saying there is nothing worthwhile in it
If I can make a suggestion - the best solution to this is not to use either if/then or a switch statement. The problem is that you're using the same ActionListener to respond to lots of different events. It seems to be commonly used in lots of examples, but I think it's a really poor design. A much more object-oriented solution is to have a different ActionListener for each event. That way, you don't have to do any checking within the methods at all.
jeff, the reason i have to make that comparison is because the yes and no buttons mean something different in that context than they do the rest of the time. as for the constants, i could have just used string literals like "Yes" and "Begin" but the Constants class is a part of the MVC framework i am using.