Chapter 1: Refactoring, a First ExampleThe Starting PointThe First Step in RefactoringDecomposing and Redistributing the Statement MethodReplacing the Conditional Logic on Price Code with PolymorphismFinal ThoughtsChapter 2: Principles in RefactoringDefining RefactoringWhy Should You Refactor?Refactoring Helps You Find BugsWhen Should You Refactor?What Do I Tell My Manager?Problems with RefactoringRefactoring and DesignRefactoring and PerformanceWhere Did Refactoring Come From?Chapter 3: Bad Smells in CodeDuplicated CodeLong MethodLarge ClassLong Parameter ListDivergent ChangeShotgun SurgeryFeature EnvyData ClumpsPrimitive ObsessionSwitch StatementsParallel Inheritance HierarchiesLazy ClassSpeculative GeneralityTemporary FieldMessage ChainsMiddle ManInappropriate IntimacyAlternative Classes with Different InterfacesIncomplete Library ClassData ClassRefused BequestCommentsChapter 4: Building TestsThe Value of Self-testing CodeThe JUnit Testing FrameworkAdding More TestsChapter 5: Toward a Catalog of RefactoringsFormat of the RefactoringsFinding ReferencesHow Mature Are These Refactorings?Chapter 6: Composing MethodsExtract MethodInline MethodInline TempReplace Temp with QueryIntroduce Explaining VariableSplit Temporary VariableRemove Assignments to ParametersReplace Method with Method ObjectSubstitute AlgorithmChapter 7: Moving Features Between ObjectsMove MethodMove FieldExtract ClassInline ClassHide DelegateRemove Middle ManIntroduce Foreign MethodIntroduce Local ExtensionChapter 8: Organizing DataSelf Encapsulate FieldReplace Data Value with ObjectChange Value to ReferenceChange Reference to ValueReplace Array with ObjectDuplicate Observed DataChange Unidirectional Association to BidirectionalChange Bidirectional Association to UnidirectionalReplace Magic Number with Symbolic ConstantEncapsulate FieldEncapsulate CollectionReplace Record with Data ClassReplace Type Code with ClassReplace Type Code with SubclassesReplace Type Code with State/StrategyReplace Subclass with FieldsChapter 9: Simplifying Conditional ExpressionsDecompose ConditionalConsolidate Conditional ExpressionConsolidate Duplicate Conditional FragmentsRemove Control FlagReplace Nested Conditional with Guard ClausesReplace Conditional with PolymorphismIntroduce Null ObjectIntroduce AssertionChapter 10: Making Method Calls SimplerRename MethodAdd ParameterRemove ParameterSeparate Query from ModifierParameterize MethodReplace Parameter with Explicit MethodsPreserve Whole ObjectReplace Parameter with MethodIntroduce Parameter ObjectRemove Setting MethodHide MethodReplace Constructor with Factory MethodEncapsulate DowncastReplace Error Code with ExceptionReplace Exception with TestChapter 11: Dealing with GeneralizationPull Up FieldPull Up MethodPull Up Constructor BodyPush Down MethodPush Down FieldExtract SubclassExtract SuperclassExtract InterfaceCollapse HierarchyForm Template MethodReplace Inheritance with DelegationReplace Delegation with InheritanceChapter 12:  Big RefactoringsTease Apart InheritanceConvert Procedural Design to ObjectsSeparate Domain from PresentationExtract HierarchyChapter 13: Refactoring, Reuse, and RealityA Reality CheckWhy Are Developers Reluctant to Refactor Their Programs?A Reality Check (Revisited)Resources and References for RefactoringImplications Regarding Software Reuse and Technology TransferA Final NoteEndnotesChapter 14: Refactoring ToolsRefactoring with a ToolTechnical Criteria for a Refactoring ToolPractical Criteria for a Refactoring ToolWrap UpChapter 15: Putting It All TogetherAbout Book:As the application of object technology--particularly the Java programming language--has become commonplace, a new problem has emerged to confront the software development community. Significant numbers of poorly designed programs have been created by less-experienced developers, resulting in applications that are inefficient and hard to maintain and extend. Increasingly, software system professionals are discovering just how difficult it is to work with these inherited, non-optimal applications. For several years, expert-level object programmers have employed a growing collection of techniques to improve the structural integrity and performance of such existing software programs. Referred to as refactoring, these practices have remained in the domain of experts because no attempt has been made to transcribe the lore into a form that all developers could use. . .until now. In Refactoring: Improving the Design of Existing Software, renowned object technology mentor Martin Fowler breaks new ground, demystifying these master practices and demonstrating how software practitioners can realize the significant benefits of this new process. With proper training a skilled system design.