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:

• RenameClass (including RenameClassInVbClassic)

Composing Methods:

• ExtractMethod (= ComposedMethod from SmalltalkBestPracticePatterns by KentBeck)
• ComposeMethod
• InlineMethod
• RemoveAssignmentsToParameters?
• ReplaceMethodWithMethodObject
• MovingFeaturesBetweenObjects?
• MoveMethod
• MoveField
• ExtractClass
• InlineClass
• HideDelegate?
• RemoveMiddleMan?
• IntroduceForeignMethod?
• IntroduceLocalExtension

Within Methods:

• InlineTemp?
• ReplaceTempWithQuery
• IntroduceExplainingVariable
• SplitTemporaryVariable
• SubstituteAlgorithm?
• RefactorIntroduceWith (new)
• RefactorEliminateWith (new)
• RefactorMatchLoopToUsage (new)
• RefactorNegateIf, RefactorDefaultOrElse, ReverseConditional (new)
• RefactorRenestBlocks (new)
• HugeCaseStatements (new) - replaces if/elseif/elseif... with Java trick that uses metadata

Organizing Data:

• SelfEncapsulateField
• ReplaceDataValueWithObject
• ChangeValueToReference?
• ChangeReferenceToValue?
• ReplaceArrayWithObject?
• DuplicateObservedData?
• ChangeUnidirectionalAssociationToBidirectional?
• ChangeBidirectionalAssociationToUnidirectional?
• ReplaceMagicNumberWithSymbolicConstant (see MagicNumber for more examples)
• EncapsulateField
• EncapsulateCollection?
• ReplaceRecordWithDataClass (VisualBasic: VbClassicRefactorTypeToClass, C++: CppRefactorStructToClass)
• ReplaceTypeCodeWithClass
• ReplaceTypeCodeWithSubclasses?
• ReplaceTypeCodeWithStateStrategy
• ReplaceSubclassWithFields?
• SimplifyingConditionalExpressions?
• DecomposeConditional
• ConsolidateConditionalExpression?
• ConsolidateDuplicateConditionalFragments
• RemoveControlFlag?
• ReplaceNestedConditionalWithGuardClauses?
• ReplaceConditionalWithPolymorphism
• IntroduceNullObject
• IntroduceAssertion?
• ExtendToImplementInterfaces - to abstract a class' interface, when you can't change the class.
• BehaviorToState
• ReplaceRecordedHistoryWithEventNotification

Making Method Calls Simpler:

• RenameMethod
• AddParameter?
• RemoveParameter?
• SeparateQueryFromModifier?
• ParameterizeMethod
• ReplaceParameterWithExplicitMethods?
• PreserveWholeObject
• ReplaceParameterWithMethod?
• IntroduceParameterObject
• RemoveSettingMethod?
• HideMethod?
• ReplaceConstructorWithFactoryMethod
• EncapsulateDowncast?
• ReplaceErrorCodeWithException?
• ReplaceExceptionWithTest?
• RefactorReorderParameters
• RefactorParametersToMemberVariables
• RefactorScopedVariableToParameter

Dealing With Generalization:

• PullUpField?
• PullUpMethod?
• PullUpConstructorBody?
• PushDownMethod?
• PushDownField?
• ExtractSubclass?
• ExtractSuperclass
• ExtractInterface
• CollapseHierarchy
• FormTemplateMethod?
• ReplaceInheritanceWithDelegation?
• ReplaceDelegationWithInheritance?
• RefactoringClassToBePolymorphic (new)

MetaRefactoring:

• ReplaceCodeWithData?
• ReplaceDataWithCode?
• IntroduceCodeGenerator

BigRefactorings: (originally described by MartinFowler)

• TeaseApartInheritance?
• ConvertProceduralDesignToObjects?
• SeparateDomainFromPresentation
• ExtractHierarchy?

RefactoringLegacyCode:

• RefactorInsertComment?
• RefactorReplaceCommentWithTestCase
• NonInvasiveRefactoring?

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:

• RefactorExtractMethodCallsToAspect
• RefactorExtractExceptionHandlingToAspect
• RefactorConcurrencyControlToAspect

---

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