In most commercial applications that I have worked with, I have found a curious pattern that continues to emerge – the Case Statement From Hell pattern.  This pattern can be found in any language which has a switch/case, select/case or other form of case statement and is often found in a method which is handling GUI code.  The Case Statement From Hell usually emerges in an event handler which has to process parameters.  These parameters may be in the form of an enum, but in most cases are usually strings.  The Case Statement From Hell has a variable length, but can quite often stretch for thousands of lines of code, violating the “avoid writing long methods” principle of good object oriented design.

If you have seen the Case Statement From Hell pattern, you know what I mean.  If you have not seen the Case Statement From Hell pattern then either you aren’t a developer, or you are a developer and I really, really want to work where you’re working.  Nevertheless, these giant case statements can usually be re-factored easily enough.  They key to doing so is to think a little bit about what the case statement is trying to accomplish. Continue reading →