HugeCaseStatements - replaces if/elseif/elseif... with Java trick that uses metadata -- (It's not really a Java trick. Well, okay, it is, but it doesn't have to be. You could keep a Hashtable around with String to Class (or String to Instance if you're using Flyweights and want to save the time it takes to create the class), and use that instead of the Class.forName(). Indeed, when I mention that the code could be optimized for speed, the optimization is to stick the classes in a Hashtable, and check there before creating new ones.)
Of course, if you want to see the real dictionary for this language, go buy the book:RefactoringImprovingTheDesignOfExistingCode.
Hear, hear. I've just finished reading the essay-type sections, and I now don't want to design my next application, but instead let the design evolve from the code. Unfortunately, my manager is one of the lots-of-upfront-design types. Oh well, maybe we can strike a compromise in the middle.
Easy: Ensure that you have plenty of unit tests. If the design isn't testable, then file a bug against it (BDUF people probably don't like the idea of untestable things, so they'll fix it). In 6 months time, when the design is hopelessly out of date, you'll have a good case for refactoring: Anyone counting beans will see the cost advantage at that point.CategoryRefactoring