Refactoring: Improving the Design of Existing Code by ...

1 Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck (Contributor), John brant (Contributor), William Opdyke, don Roberts Another stupid release 2002J For all the people which doesn t have money to buy a good book 2 Your class library works, but could it be better? Refactoring: Improving the Design of Existing Code shows how refactoring can make object-oriented code simpler and easier to maintain. Today refactoring requires considerable Design know-how, but once tools become available, all programmers should be able to improve their code using refactoring techniques. Besides an introduction to refactoring, this handbook provides a catalog of dozens of tips for Improving code. The best thing about Refactoring is its remarkably clear presentation, along with excellent nuts-and-bolts advice, from object expert Martin Fowler.

2 The author is also an authority on software patterns and UML, and this experience helps make this a better book, one that should be immediately accessible to any intermediate or advanced object-oriented developer. (Just like patterns, each refactoring tip is presented with a simple name, a "motivation," and examples using Java and UML.) Early chapters stress the importance of testing in successful refactoring. (When you improve code, you have to test to verify that it still works.) After the discussion on how to detect the "smell" of bad code, readers get to the heart of the book, its catalog of over 70 "refactorings"--tips for better and simpler class Design . Each tip is illustrated with "before" and "after" code, along with an explanation. Later chapters provide a quick look at refactoring research. Like software patterns, refactoring may be an idea whose time has come.

3 This groundbreaking title will surely help bring refactoring to the programming mainstream. With its clear advice on a hot new topic, Refactoring is sure to be essential reading for anyone who writes or maintains object-oriented software. --Richard Dragan Topics Covered: Refactoring, Improving software code, redesign, Design tips, patterns, unit testing, refactoring research, and tools. Book News, Inc. A guide to refactoring, the process of changing a software system so that it does not alter the external behavior of the code yet improves its internal structure, for professional programmers. Early chapters cover general principles, rationales, examples, and testing. The heart of the book is a catalog of refactorings, organized in chapters on composing methods, moving features between objects, organizing data, simplifying conditional expressions, and dealing with generalizations 3 What Is Refactoring?

4 9 What's in This Book?..9 Who Should Read This Book?..10 Building on the Foundations Laid by Chapter 1. Refactoring, a First The Starting The First Step in Decomposing and Redistributing the Statement Replacing the Conditional Logic on Price Code with Final Chapter 2. Principles in Defining Why Should You Refactor?..47 Refactoring Helps You Find When Should You Refactor?..49 What Do I Tell My Manager?..52 Problems with Refactoring and Refactoring and Where Did Refactoring Come From?..60 Chapter 3. Bad Smells in Duplicated Long Large Long Parameter Divergent Shotgun Feature Data Primitive Switch Parallel Inheritance Lazy Speculative Temporary Message Middle Inappropriate Alternative Classes with Different Incomplete Library Data Refused Chapter 4. Building The Value of Self-testing The JUnit Testing Adding More Chapter 5.

5 Toward a Catalog of Format of the Finding How Mature Are These Refactorings?..87 Chapter 6. Composing Extract Inline Inline Replace Temp with Introduce Explaining Split Temporary Remove Assignments to Replace Method with Method Substitute Chapter 7. Moving Features Between Move Move Extract Inline Hide Remove Middle Introduce Foreign Introduce Local Chapter 8. Organizing Self Encapsulate Replace Data Value with Change Value to Change Reference to Replace Array with Duplicate Observed Change Unidirectional Association to Change Bidirectional Association to Replace Magic Number with Symbolic Encapsulate Encapsulate Replace Record with Data Replace Type Code with Replace Type Code with Replace Type Code with Replace Subclass with Chapter 9. Simplifying Conditional 5 Decompose Consolidate Conditional Consolidate Duplicate Conditional Remove Control Replace Nested Conditional with Guard Replace Conditional with Introduce Null Introduce Chapter 10.

6 Making Method Calls Rename Add Remove Separate Query from Parameterize Replace Parameter with Explicit Preserve Whole Replace Parameter with Introduce Parameter Remove Setting Hide Replace Constructor with Factory Encapsulate Replace Error Code with Replace Exception with Chapter 11. Dealing with Pull Up Pull Up Pull Up Constructor Push Down Push Down Extract Extract Extract Collapse Form Template Replace Inheritance with Replace Delegation with Chapter 12. Big Tease Apart Convert Procedural Design to Separate Domain from Extract Chapter 13. Refactoring, Reuse, and A Reality Why Are Developers Reluctant to Refactor Their Programs?..312 A Reality Check (Revisited)..323 6 Resources and References for Implications Regarding Software Reuse and Technology A Final Chapter 14.

7 Refactoring Refactoring with a Technical Criteria for a Refactoring Practical Criteria for a Refactoring Wrap Chapter 15. Putting It All Foreword "Refactoring" was conceived in Smalltalk circles, but it wasn't long before it found its way into other programming language camps. Because refactoring is integral to framework development, the term comes up quickly when "frameworkers" talk about their craft. It comes up when they refine their class hierarchies and when they rave about how many lines of code they were able to delete. Frameworkers know that a framework won't be right the first time around it must evolve as they gain experience. They also know that the code will be read and modified more frequently than it will be written. The key to keeping code readable and modifiable is refactoring for frameworks, in particular, but also for software in general.

8 So, what's the problem? Simply this: Refactoring is risky. It requires changes to working code that can introduce subtle bugs. Refactoring, if not done properly, can set you back days, even weeks. And refactoring becomes riskier when practiced informally or ad hoc. You start digging in the code. Soon you discover new opportunities for change, and you dig deeper. The more you dig, the more stuff you turn the more changes you make. Eventually you dig yourself into a hole you can't get out of. To avoid digging your own grave, refactoring must be done systematically. When my coauthors and I wrote Design Patterns, we mentioned that Design patterns provide targets for refactorings. However, identifying the target is only one part of the problem; transforming your code so that you get there is another challenge. Martin Fowler and the contributing authors make an invaluable contribution to object-oriented software development by shedding light on the refactoring process.

9 This book explains the principles and best practices of refactoring, and points out when and where you should start digging in your code to improve it. At the book's core is a comprehensive catalog of refactorings. Each refactoring describes the motivation and mechanics of a proven code transformation. Some of the refactorings, such as Extract Method or Move Field, may seem obvious. But don't be fooled. Understanding the mechanics of such refactorings is the key to refactoring in a disciplined way. The refactorings in this book will help you change your code one small step at a time, thus reducing the risks of evolving your Design . You will quickly add these refactorings and their names to your development vocabulary. My first experience with disciplined, "one step at a time" refactoring was when I was pair-programming at 30,000 feet with Kent Beck.

10 He made sure that we applied refactorings from this book's catalog one step at a time. I was amazed at how well this practice worked. Not only did my confidence in the resulting code increase, I also felt less stressed. I highly recommend you try these refactorings: You and your code will feel much better for it. 7 Erich Gamma Object Technology International, Inc. 8 Preface Once upon a time, a consultant made a visit to a development project. The consultant looked at some of the code that had been written; there was a class hierarchy at the center of the system. As he wandered through the hierarchy, the consultant saw that it was rather messy. The higher-level classes made certain assumptions about how the classes would work, assumptions that were embodied in inherited code. That code didn't suit all the subclasses, however, and was overridden quite heavily.