Refactoring Language
MartinFowler's book RefactoringImprovingTheDesignOfExistingCode may do for refactoring what DesignPatterns did for design: create a language (a system of words) that we can use to express our refactoring thoughts.
The catalog from the book, with additions, is at http://www.refactoring.com/catalog/.
Organizing Classes:
Composing Methods:
Within Methods:
Organizing Data:
Making Method Calls Simpler:
Dealing With Generalization:
MetaRefactoring:
BigRefactorings:
(originally described by MartinFowler)
RefactoringLegacyCode:
JavaLanguage Specific: (RefactoringIdioms?)
- 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.)
- ExtractPackage? - "A package either has too many classes to be easily understandable or it suffers from the 'Promiscuous packages' smell." -- Gerard M. Davison. See http://www.refactoring.com/catalog/extractPackage.html
AspectOrientedRefactoring:
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
EditText of this page (last edited May 13, 2005)
FindPage by browsing or searching
This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006