Refactoring: Improving the Design of Existing Code / Edition 1

Other Format (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $38.49
Usually ships in 1-2 business days
(Save 40%)
Other sellers (Other Format)
  • All (16) from $38.49   
  • New (6) from $43.02   
  • Used (10) from $38.49   

Overview

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 Code, 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 designer can take a bad design and rework it into well-designed, robust code. In this book, Martin Fowler shows you where opportunities for refactoring typically can be found, and how to go about reworking a bad design into a good one. Each refactoring step is simple--seemingly too simple to be worth doing. Refactoring may involve moving a field from one class to another, or pulling some code out of a method to turn it into its own method, or even pushing some code up or down a hierarchy. While these individual steps may seem elementary, the cumulative effect of such small changes can radically improve the design. Refactoring is a proven way to prevent software decay.

In addition to discussing the various techniques of refactoring, the author provides a detailed catalog of more than seventy proven refactorings with helpful pointers that teach you when to apply them; step-by-step instructions for applying each refactoring; and an example illustrating how the refactoring works. The illustrative examples are written in Java, but the ideas are applicable to any object-oriented programming language.

Read More Show Less

Editorial Reviews

Booknews
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. Later chapters describe issues in adopting refactoring in commercial development, automated tools, and the future of refactoring. Java is used for all examples. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780201485677
  • Publisher: Addison-Wesley
  • Publication date: 6/11/1999
  • Series: Addison-Wesley Object Technology Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 464
  • Sales rank: 432,306
  • Product dimensions: 7.72 (w) x 9.53 (h) x 1.29 (d)

Meet the Author

Martin Fowler is the Chief Scientist of ThoughtWorks, an enterprise-application development and delivery company. He's been applying object-oriented techniques to enterprise software development for over a decade. He is notorious for his work on patterns, the UML, refactoring, and agile methods. Martin lives in Melrose, Massachusetts, with his wife, Cindy, and a very strange cat. His homepage is http://martinfowler.com.

Kent Beck consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Agitar Software, he is the author of many Addison-Wesley titles.

John Brant and Don Roberts are the authors of the Refactoring Browser for Smalltalk, which is found at http://st-www.cs.uiuc.edu/~brant/RefactoringBrowser/. They are also consultants who have studied both the practical and theoretical aspects of refactoring for six years.

William Opdyke's doctoral research on refactoring object-oriented frameworks at the University of Illinois led to the first major publication on this topic. He is currently a Distinguished Member of Technical Staff at Lucent Technologies/Bell Laboratories.

John Brant and Don Roberts are the authors of the Refactoring Browser for Smalltalk, which is found at http://st-www.cs.uiuc.edu/~brant/RefactoringBrowser/. They are also consultants who have studied both the practical and theoretical aspects of refactoring for six years.

Read More Show Less

Read an Excerpt

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. If the superclass had been modified a little, then much less overriding would have been necessary. In other places some of the intention of the superclass had not been properly understood, and behavior present in the superclass was duplicated. In yet other places several subclasses did the same thing with code that could clearly be moved up the hierarchy.

The consultant recommended to the project management that the code be looked at and cleaned up, but the project management didn't seem enthusiastic. The code seemed to work and there were considerable schedule pressures. The managers said they would get around to it at some later point.

The consultant had also shown the programmers who had worked on the hierarchy what was going on. The programmers were keen and saw the problem. They knew that it wasn't really their fault; sometimes a new pair of eyes are needed to spot the problem. So the programmers spent a day or two cleaning up the hierarchy. When they were finished, the programmers had removed half the code in the hierarchy without reducing its functionality. They were pleased with the result and found that it became quicker and easier both to add new classes to the hierarchy and to use the classes in the rest of the system.

The project management was not pleased. Schedules were tight and there was a lot of work to do. These two programmers had spent two days doing work that had done nothing to add the many features the system had to deliver in a few months time. The old code had worked just fine. So the design was a bit more "pure" a bit more "clean." The project had to ship code that worked, not code that would please an academic. The consultant suggested that this cleaning up be done on other central parts of the system. Such an activity might halt the project for a week or two. All this activity was devoted to making the code look better, not to making it do anything that it didn't already do.

How do you feel about this story? Do you think the consultant was right to suggest further clean up? Or do you follow that old engineering adage, "if it works, don't fix it"?

I must admit to some bias here. I was that consultant. Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance.

The consultant Kent Beck was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring. The success of this project, and role refactoring played in this success, is what inspired me to write this book, so that I could pass on the knowledge that Kent and others have learned in using refactoring to improve the quality of software.

What Is Refactoring?

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.

"Improving the design after it has been written." That's an odd turn of phrase. In our current understanding of software development we believe that we design and then we code. A good design comes first, and the coding comes second. Over time the code will be modified, and the integrity of the system, its structure according to that design, gradually fades. The code slowly sinks from engineering to hacking.

Refactoring is the opposite of this practice. With refactoring you can take a bad design, chaos even, and rework it into well-designed code. Each step is simple, even simplistic. You move a field from one class to another, pull some code out of a method to make into its own method, and push some code up or down a hierarchy. Yet the cumulative effect of these small changes can radically improve the design. It is the exact reverse of the normal notion of software decay.

With refactoring you find the balance of work changes. You find that design, rather than occurring all up front, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues.

What's in This Book?

This book is a guide to refactoring; it is written for a professional programmer. My aim is to show you how to do refactoring in a controlled and efficient manner. You will learn to refactor in such a way that you don't introduce bugs into the code but instead methodically improve the structure.

It's traditional to start books with an introduction. Although I agree with that principle, I don't find it easy to introduce refactoring with a generalized discussion or definitions. So I start with an example. Chapter 1 takes a small program with some common design flaws and refactors it into a more acceptable object-oriented program. Along the way we see both the process of refactoring and the application of several useful refactorings. This is the key chapter to read if you want to understand what refactoring really is about.

In Chapter 2 I cover more of the general principles of refactoring, some definitions, and the reasons for doing refactoring. I outline some of the problems with refactoring. In Chapter 3 Kent Beck helps me describe how to find bad smells in code and how to clean them up with refactorings. Testing plays a very important role in refactoring, so Chapter 4 describes how to build tests into code with a simple open-source Java testing framework.

The heart of the book, the catalog of refactorings, stretches from Chapter 5 through Chapter 12. This is by no means a comprehensive catalog. It is the beginning of such a catalog. It includes the refactorings that I have written down so far in my work in this field. When I want to do something, such as Replace Conditional with Polymorphism (255), the catalog reminds me how to do it in a safe, step-by-step manner. I hope this is the section of the book you'll come back to often.

In this book I describe the fruit of a lot of research done by others. The last chapters are guest chapters by some of these people. Chapter 13 is by Bill Opdyke, who describes the issues he has come across in adopting refactoring in commercial development. Chapter 14 is by Don Roberts and John Brant, who describe the true future of refactoring, automated tools. I've left the final word, Chapter 15, to the master of the art, Kent Beck.

Refactoring in Java

For all of this book I use examples in Java. Refactoring can, of course, be done with other languages, and I hope this book will be useful to those working with other languages. However, I felt it would be best to focus this book on Java because it is the language I know best. I have added occasional notes for refactoring in other languages, but I hope other people will build on this foundation with books aimed at specific languages.

To help communicate the ideas best, I have not used particularly complex areas of the Java language. So I've shied away from using inner classes, reflection, threads, and many other of Java's more powerful features. This is because I want to focus on the core refactorings as clearly as I can.

I should emphasize that these refactorings are not done with concurrent or distributed programming in mind. Those topics introduce additional concerns that are beyond the scope of this book.

Who Should Read This Book?

This book is aimed at a professional programmer, someone who writes software for a living. The examples and discussion include a lot of code to read and understand. The examples are all in Java. I chose Java because it is an increasingly well-known language that can be easily understood by anyone with a background in C. It is also an object-oriented language, and object-oriented mechanisms are a great help in refactoring.

Although it is focused on the code, refactoring has a large impact on the design of system. It is vital for senior designers and architects to understand the principles of refactoring and to use them in their projects. Refactoring is best introduced by a respected and experienced developer. Such a developer can best understand the principles behind refactoring and adapt those principles to the specific workplace. This is particularly true when you are using a language other than Java, because you have to adapt the examples I've given to other languages.

Here's how to get the most from this book without reading all of it.

  • If you want to understand what refactoring is, read Chapter 1; the example should make the process clear.
  • If you want to understand why you should refactor, read the first two chapters. They will tell you what refactoring is and why you should do it.
  • If you want to find where you should refactor, read Chapter 3. It tells you the signs that suggest the need for refactoring.
  • If you want to actually do refactoring, read the first four chapters completely. Then skip-read the catalog. Read enough of the catalog to know roughly what is in there. You don't have to understand all the details. When you actually need to carry out a refactoring, read the refactoring in detail and use it to help you. The catalog is a reference section, so you probably won't want to read it in one go. You should also read the guest chapters, especially Chapter 15.
Building on the Foundations Laid by Others

I need to say right now, at the beginning, that I owe a big debt with this book, a debt to those whose work over the last decade has developed the field of refactoring. Ideally one of them should have written this book, but I ended up being the one with the time and energy.

Two of the leading proponents of refactoring are Ward Cunningham and Kent Beck. They used it as a central part of their development process in the early days and have adapted their development processes to take advantage of it. In particular it was my collaboration with Kent that really showed me the importance of refactoring, an inspiration that led directly to this book.

Ralph Johnson leads a group at the University of Illinois at Urbana-Champaign that is notable for its practical contributions to object technology. Ralph has long been a champion of refactoring, and several of his students have worked on the topic. Bill Opdyke developed the first detailed written work on refactoring in his doctoral thesis. John Brant and Don Roberts have gone beyond writing words into writing a tool, the Refactoring Browser, for refactoring Smalltalk programs.

Acknowledgments

Even with all that research to draw on, I still needed a lot of help to write this book. First and foremost, Kent Beck was a huge help. The first seeds were planted in a bar in Detroit when Kent told me about a paper he was writing for the Smalltalk Report Beck, hanoi. It not only provided many ideas for me to steal for Chapter 1 but also started me off in taking notes of refactorings. Kent helped in other places too. He came up with the idea of code smells, encouraged me at various sticky points, and generally worked with me to make this book work. I can't help thinking he could have written this book much better himself, but I had the time and can only hope I did the subject justice.

As I've written this, I wanted to share much of this expertise directly with you, so I'm very grateful that many of these people have spent some time adding some material to this book. Kent Beck, John Brant, William Opdyke, and Don Roberts have all written or co-written chapters. In addition, Rich Garzaniti and Ron Jeffries have added useful sidebars.

Any author will tell you that technical reviewers do a great deal to help in a book like this. As usual, Carter Shanklin and his team at Addison-Wesley put together a great panel of hard-nosed reviewers. These were

  • Ken Auer, Rolemodel Software, Inc.
  • Joshua Bloch, Javasoft
  • John Brant, University of Illinois at Urbana-Champaign
  • Scott Corley, High Voltage Software, Inc.
  • Ward Cunningham, Cunningham & Cunningham, Inc.
  • Stephane Ducasse
  • Erich Gamma, Object Technology International, Inc.
  • Ron Jeffries
  • Ralph Johnson, University of Illinois
  • Joshua Kerievsky, Industrial Logic, Inc.
  • Doug Lea, SUNY Oswego
  • Sander Tichelaar

They all added a great deal to the readability and accuracy of this book, and removed at least some of the errors that can lurk in any manuscript. I'd like to highlight a couple of very visible suggestions that made a difference to the look of the book. Ward and Ron got me to do Chapter 1 in the side-by-side style. Joshua suggested the idea of the code sketches in the catalog.

In addition to the official review panel there were many unofficial reviewers. These people looked at the manuscript or the work in progress on my Web pages and made helpful comments. They include Leif Bennett, Michael Feathers, Michael Finney, Neil Galarneau, Hisham Ghazouli, Tony Gould, John Isner, Brian Marick, Ralf Reissing, John Salt, Mark Swanson, Dave Thomas, and Don Wells. I'm sure there are others who I've forgotton; I apologize and offer my thanks.

A particularly entertaining review group is the infamous reading group at the University of Illinois at Urbana-Champaign. Because this book reflects so much of their work, I'm particularly grateful for their efforts captured in real audio. This group includes Fredrico "Fred" Balaguer, John Brant, Ian Chai, Brian Foote, Alejandra Garrido, Zhijiang "John" Han, Peter Hatch, Ralph Johnson, Songyu "Raymond" Lu, Dragos-Anton Manolescu, Hiroaki Nakamura, James Overturf, Don Roberts, Chieko Shirai, Les Tyrell, and Joe Yoder.

Any good idea needs to be tested in a serious production system. I saw refactoring have a huge effect on the Chrysler Comprehensive Compensation system (C3). I want to thank all the members of that team: Ann Anderson, Ed Anderi, Ralph Beattie, Kent Beck, David Bryant, Bob Coe, Marie DeArment, Margaret Fronczak, Rich Garzaniti, Dennis Gore, Brian Hacker, Chet Hendrickson, Ron Jeffries, Doug Joppie, David Kim, Paul Kowalsky, Debbie Mueller, Tom Murasky, Richard Nutter, Adrian Pantea, Matt Saigeon, Don Thomas, and Don Wells. Working with them cemented the principles and benefits of refactoring into me on a firsthand basis. Watching their progress as they use refactoring heavily helps me see what refactoring can do when applied to a large project over many years.

Again I had the help of J. Carter Shanklin at Addison-Wesley and his team: Krysia Bebick, Susan Cestone, Chuck Dutton, Kristin Erickson, John Fuller, Christopher Guzikowski, Simone Payment, and Genevieve Rajewski. Working with a good publisher is a pleasure; they provided a lot of support and help.

Talking of support, the biggest sufferer from a book is always the closest to the author, in this case my (now) wife Cindy. Thanks for loving me even when I was hidden in the study. As much time as I put into this book, I never stopped being distracted by thinking of you.

—Martin Fowler Melrose, Massachusetts
fowler@acm.org
http://ourworld.compuserve.com/homepages/martin_fowler

0201485672P04062001

Read More Show Less

Table of Contents

1. Refactoring, a First Example.

The Starting Point.

The First Step in Refactoring.

Decomposing and Redistributing the Statement Method.

Replacing the Conditional Logic on Price Code with Polymorphism.

Final Thoughts.

2. Principles in Refactoring.

Defining Refactoring.

Why Should You Refactor?

When Should You Refactor?

What Do I Tell My Manager?

Problems with Refactoring.

Refactoring and Design.

Refactoring and Performance.

Where Did Refactoring Come From?

3. Bad Smells in Code.

Duplicated Code.

Long Method.

Large Class.

Long Parameter List.

Divergent Change.

Shotgun Surgery.

Feature Envy.

Data Clumps.

Primitive Obsession.

Switch Statements.

Parallel Inheritance Hierarchies.

Lazy Class.

Speculative Generality.

Temporary Field.

Message Chains.

Middle Man.

Inappropriate Intimacy.

Alternative Classes with Different Interfaces.

Incomplete Library Class.

Data Class.

Refused Bequest.

Comments.

4. Building Tests.

The Value of Self-testing Code.

The JUnit Testing Framework.

Adding More Tests.

5. Toward a Catalog of Refactorings.

Format of the Refactorings.

Finding References.

How Mature Are These Refactorings?

6. Composing Methods.

Extract Method.

Inline Method.

Inline Temp.

Replace Temp with Query.

Introduce Explaining Variable.

Split Temporary Variable.

Remove Assignments to Parameters.

Replace Method with Method Object.

Substitute Algorithm.

7. Moving Features Between Objects.

Move Method.

Move Field.

Extract Class.

Inline Class.

Hide Delegate.

Remove Middle Man.

Introduce Foreign Method.

Introduce Local Extension.

8. Organizing Data.

Self Encapsulate Field.

Replace Data Value with Object.

Change Value to Reference.

Change Reference to Value.

Replace Array with Object.

Duplicate Observed Data.

Change Unidirectional Association to Bidirectional.

Change Bidirectional Association to Unidirectional.

Replace Magic Number with Symbolic Constant.

Encapsulate Field.

Encapsulate Collection.

Replace Record with Data Class.

Replace Type Code with Class.

Replace Type Code with Subclasses.

Replace Type Code with State/Strategy.

Replace Subclass with Fields.

9. Simplifying Conditional Expressions.

Decompose Conditional.

Consolidate Conditional Expression.

Consolidate Duplicate Conditional Fragments.

Remove Control Flag.

Replace Nested Conditional with Guard Clauses.

Replace Conditional with Polymorphism.

Introduce Null Object.

Introduce Assertion.

10. Making Method Calls Simpler.

Rename Method.

Add Parameter.

Remove Parameter.

Separate Query from Modifier.

Parameterize Method.

Replace Parameter with Explicit Methods.

Preserve Whole Object.

Replace Parameter with Method.

Introduce Parameter Object.

Remove Setting Method.

Hide Method.

Replace Constructor with Factory Method.

Encapsulate Downcast.

Replace Error Code with Exception.

Replace Exception with Test.

11. Dealing with Generalization.

Pull Up Field.

Pull Up Method.

Pull Up Constructor Body.

Push Down Method.

Push Down Field.

Extract Subclass.

Extract Superclass.

Extract Interface.

Collapse Hierarchy.

Form Template Method.

Replace Inheritance with Delegation.

Replace Delegation with Inheritance.

12. Big Refactorings.

Tease Apart Inheritance.

Convert Procedural Design to Objects.

Separate Domain from Presentation.

Extract Hierarchy.

13. Refactoring, Reuse, and Reality.

A Reality Check.

Why Are Developers Reluctant to Refactor Their Programs?

A Reality Check (Revisited).

Resources and References for Refactoring.

Implications Regarding Software Reuse and Technology Transfer.

A Final Note.

References.

14. Refactoring Tools.

Refactoring with a Tool.

Technical Criteria for a Refactoring Tool.

Practical Criteria for a Refactoring Tool.

Wrap Up.

15. Putting It All Together.

References.

List of Soundbites.

List of Refactorings.

Index. 0201485672T04062001

Read More Show Less

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. If the superclass had been modified a little, then much less overriding would have been necessary. In other places some of the intention of the superclass had not been properly understood, and behavior present in the superclass was duplicated. In yet other places several subclasses did the same thing with code that could clearly be moved up the hierarchy.

The consultant recommended to the project management that the code be looked at and cleaned up, but the project management didn't seem enthusiastic. The code seemed to work and there were considerable schedule pressures. The managers said they would get around to it at some later point.

The consultant had also shown the programmers who had worked on the hierarchy what was going on. The programmers were keen and saw the problem. They knew that it wasn't really their fault; sometimes a new pair of eyes are needed to spot the problem. So the programmers spent a day or two cleaning up the hierarchy. When they were finished, the programmers had removed half the code in the hierarchy without reducing its functionality. They were pleased with the result and found that it became quicker and easier both to add new classes to the hierarchy and to use the classes in the rest of the system.

The project management was not pleased. Schedules were tight and there was a lot of work to do. These two programmers had spent two days doing work that had done nothing to add the many features the system had to deliver in a few months time. The old code had worked just fine. So the design was a bit more "pure" a bit more "clean." The project had to ship code that worked, not code that would please an academic. The consultant suggested that this cleaning up be done on other central parts of the system. Such an activity might halt the project for a week or two. All this activity was devoted to making the code look better, not to making it do anything that it didn't already do.

How do you feel about this story? Do you think the consultant was right to suggest further clean up? Or do you follow that old engineering adage, "if it works, don't fix it"?

I must admit to some bias here. I was that consultant. Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance.

The consultant Kent Beck was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring. The success of this project, and role refactoring played in this success, is what inspired me to write this book, so that I could pass on the knowledge that Kent and others have learned in using refactoring to improve the quality of software.

What Is Refactoring?

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.

"Improving the design after it has been written." That's an odd turn of phrase. In our current understanding of software development we believe that we design and then we code. A good design comes first, and the coding comes second. Over time the code will be modified, and the integrity of the system, its structure according to that design, gradually fades. The code slowly sinks from engineering to hacking.

Refactoring is the opposite of this practice. With refactoring you can take a bad design, chaos even, and rework it into well-designed code. Each step is simple, even simplistic. You move a field from one class to another, pull some code out of a method to make into its own method, and push some code up or down a hierarchy. Yet the cumulative effect of these small changes can radically improve the design. It is the exact reverse of the normal notion of software decay.

With refactoring you find the balance of work changes. You find that design, rather than occurring all up front, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues.

What's in This Book?

This book is a guide to refactoring; it is written for a professional programmer. My aim is to show you how to do refactoring in a controlled and efficient manner. You will learn to refactor in such a way that you don't introduce bugs into the code but instead methodically improve the structure.

It's traditional to start books with an introduction. Although I agree with that principle, I don't find it easy to introduce refactoring with a generalized discussion or definitions. So I start with an example. Chapter 1 takes a small program with some common design flaws and refactors it into a more acceptable object-oriented program. Along the way we see both the process of refactoring and the application of several useful refactorings. This is the key chapter to read if you want to understand what refactoring really is about.

In Chapter 2 I cover more of the general principles of refactoring, some definitions, and the reasons for doing refactoring. I outline some of the problems with refactoring. In Chapter 3 Kent Beck helps me describe how to find bad smells in code and how to clean them up with refactorings. Testing plays a very important role in refactoring, so Chapter 4 describes how to build tests into code with a simple open-source Java testing framework.

The heart of the book, the catalog of refactorings, stretches from Chapter 5 through Chapter 12. This is by no means a comprehensive catalog. It is the beginning of such a catalog. It includes the refactorings that I have written down so far in my work in this field. When I want to do something, such as Replace Conditional with Polymorphism (255), the catalog reminds me how to do it in a safe, step-by-step manner. I hope this is the section of the book you'll come back to often.

In this book I describe the fruit of a lot of research done by others. The last chapters are guest chapters by some of these people. Chapter 13 is by Bill Opdyke, who describes the issues he has come across in adopting refactoring in commercial development. Chapter 14 is by Don Roberts and John Brant, who describe the true future of refactoring, automated tools. I've left the final word, Chapter 15, to the master of the art, Kent Beck.

Refactoring in Java

For all of this book I use examples in Java. Refactoring can, of course, be done with other languages, and I hope this book will be useful to those working with other languages. However, I felt it would be best to focus this book on Java because it is the language I know best. I have added occasional notes for refactoring in other languages, but I hope other people will build on this foundation with books aimed at specific languages.

To help communicate the ideas best, I have not used particularly complex areas of the Java language. So I've shied away from using inner classes, reflection, threads, and many other of Java's more powerful features. This is because I want to focus on the core refactorings as clearly as I can.

I should emphasize that these refactorings are not done with concurrent or distributed programming in mind. Those topics introduce additional concerns that are beyond the scope of this book.

Who Should Read This Book?

This book is aimed at a professional programmer, someone who writes software for a living. The examples and discussion include a lot of code to read and understand. The examples are all in Java. I chose Java because it is an increasingly well-known language that can be easily understood by anyone with a background in C. It is also an object-oriented language, and object-oriented mechanisms are a great help in refactoring.

Although it is focused on the code, refactoring has a large impact on the design of system. It is vital for senior designers and architects to understand the principles of refactoring and to use them in their projects. Refactoring is best introduced by a respected and experienced developer. Such a developer can best understand the principles behind refactoring and adapt those principles to the specific workplace. This is particularly true when you are using a language other than Java, because you have to adapt the examples I've given to other languages.

Here's how to get the most from this book without reading all of it.

  • If you want to understand what refactoring is, read Chapter 1; the example should make the process clear.
  • If you want to understand why you should refactor, read the first two chapters. They will tell you what refactoring is and why you should do it.
  • If you want to find where you should refactor, read Chapter 3. It tells you the signs that suggest the need for refactoring.
  • If you want to actually do refactoring, read the first four chapters completely. Then skip-read the catalog. Read enough of the catalog to know roughly what is in there. You don't have to understand all the details. When you actually need to carry out a refactoring, read the refactoring in detail and use it to help you. The catalog is a reference section, so you probably won't want to read it in one go. You should also read the guest chapters, especially Chapter 15.

Building on the Foundations Laid by Others

I need to say right now, at the beginning, that I owe a big debt with this book, a debt to those whose work over the last decade has developed the field of refactoring. Ideally one of them should have written this book, but I ended up being the one with the time and energy.

Two of the leading proponents of refactoring are Ward Cunningham and Kent Beck. They used it as a central part of their development process in the early days and have adapted their development processes to take advantage of it. In particular it was my collaboration with Kent that really showed me the importance of refactoring, an inspiration that led directly to this book.

Ralph Johnson leads a group at the University of Illinois at Urbana-Champaign that is notable for its practical contributions to object technology. Ralph has long been a champion of refactoring, and several of his students have worked on the topic. Bill Opdyke developed the first detailed written work on refactoring in his doctoral thesis. John Brant and Don Roberts have gone beyond writing words into writing a tool, the Refactoring Browser, for refactoring Smalltalk programs.

Acknowledgments

Even with all that research to draw on, I still needed a lot of help to write this book. First and foremost, Kent Beck was a huge help. The first seeds were planted in a bar in Detroit when Kent told me about a paper he was writing for the Smalltalk Report Beck, hanoi. It not only provided many ideas for me to steal for Chapter 1 but also started me off in taking notes of refactorings. Kent helped in other places too. He came up with the idea of code smells, encouraged me at various sticky points, and generally worked with me to make this book work. I can't help thinking he could have written this book much better himself, but I had the time and can only hope I did the subject justice.

As I've written this, I wanted to share much of this expertise directly with you, so I'm very grateful that many of these people have spent some time adding some material to this book. Kent Beck, John Brant, William Opdyke, and Don Roberts have all written or co-written chapters. In addition, Rich Garzaniti and Ron Jeffries have added useful sidebars.

Any author will tell you that technical reviewers do a great deal to help in a book like this. As usual, Carter Shanklin and his team at Addison-Wesley put together a great panel of hard-nosed reviewers. These were

  • Ken Auer, Rolemodel Software, Inc.
  • Joshua Bloch, Javasoft
  • John Brant, University of Illinois at Urbana-Champaign
  • Scott Corley, High Voltage Software, Inc.
  • Ward Cunningham, Cunningham & Cunningham, Inc.
  • Stephane Ducasse
  • Erich Gamma, Object Technology International, Inc.
  • Ron Jeffries
  • Ralph Johnson, University of Illinois
  • Joshua Kerievsky, Industrial Logic, Inc.
  • Doug Lea, SUNY Oswego
  • Sander Tichelaar

They all added a great deal to the readability and accuracy of this book, and removed at least some of the errors that can lurk in any manuscript. I'd like to highlight a couple of very visible suggestions that made a difference to the look of the book. Ward and Ron got me to do Chapter 1 in the side-by-side style. Joshua suggested the idea of the code sketches in the catalog.

In addition to the official review panel there were many unofficial reviewers. These people looked at the manuscript or the work in progress on my Web pages and made helpful comments. They include Leif Bennett, Michael Feathers, Michael Finney, Neil Galarneau, Hisham Ghazouli, Tony Gould, John Isner, Brian Marick, Ralf Reissing, John Salt, Mark Swanson, Dave Thomas, and Don Wells. I'm sure there are others who I've forgotton; I apologize and offer my thanks.

A particularly entertaining review group is the infamous reading group at the University of Illinois at Urbana-Champaign. Because this book reflects so much of their work, I'm particularly grateful for their efforts captured in real audio. This group includes Fredrico "Fred" Balaguer, John Brant, Ian Chai, Brian Foote, Alejandra Garrido, Zhijiang "John" Han, Peter Hatch, Ralph Johnson, Songyu "Raymond" Lu, Dragos-Anton Manolescu, Hiroaki Nakamura, James Overturf, Don Roberts, Chieko Shirai, Les Tyrell, and Joe Yoder.

Any good idea needs to be tested in a serious production system. I saw refactoring have a huge effect on the Chrysler Comprehensive Compensation system (C3). I want to thank all the members of that team: Ann Anderson, Ed Anderi, Ralph Beattie, Kent Beck, David Bryant, Bob Coe, Marie DeArment, Margaret Fronczak, Rich Garzaniti, Dennis Gore, Brian Hacker, Chet Hendrickson, Ron Jeffries, Doug Joppie, David Kim, Paul Kowalsky, Debbie Mueller, Tom Murasky, Richard Nutter, Adrian Pantea, Matt Saigeon, Don Thomas, and Don Wells. Working with them cemented the principles and benefits of refactoring into me on a firsthand basis. Watching their progress as they use refactoring heavily helps me see what refactoring can do when applied to a large project over many years.

Again I had the help of J. Carter Shanklin at Addison-Wesley and his team: Krysia Bebick, Susan Cestone, Chuck Dutton, Kristin Erickson, John Fuller, Christopher Guzikowski, Simone Payment, and Genevieve Rajewski. Working with a good publisher is a pleasure; they provided a lot of support and help.

Talking of support, the biggest sufferer from a book is always the closest to the author, in this case my (now) wife Cindy. Thanks for loving me even when I was hidden in the study. As much time as I put into this book, I never stopped being distracted by thinking of you.

--Martin Fowler
Melrose, Massachusetts
fowler@acm.org
http://ourworld.compuserve.com/homepages/martin_fowler

0201485672P04062001

Read More Show Less

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.

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 up. . .and 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 softwaredevelopment by shedding light on the refactoring process. 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. 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.

--Erich Gamma
Object Technology International, Inc.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 8 Customer Reviews
  • Anonymous

    Posted October 26, 2009

    I Also Recommend:

    Essential reading for professional programmers

    Refactoring is the process of changing the internal structure of a program without changing its outward behavior. If you are writing a program that you only ever intend to run once, then you have no need to refactor. If, however, you plan on maintaining and adapting your program for years to come, then you will need to know how to change it safely without producing a sloppy, fragile, top-heavy mess. The point of this book is to produce clean, bug-free source code that is easy to adapt to the ever-changing requirements of the marketplace. So this book is as much about writing clean code as it is about refactoring. It identifies around seventy refactorings, explains when you would use each one, and provides some simple source code to illustrate each one.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted February 21, 2009

    Great book for anyone refactoring code

    The book is split into two sections, the process for refactoring code and the library of patterns. The topic is explained through the actual refactoring of sample code. It is an easy read and does a great job addressing the "wrong" approach to refactoring and a step by step process for doing it right. The website contains a more detailed and complex example of refactoring - the missing chapter.

    Fowler address the issues with the actual code but I would have liked some discussions on database migration issues. The code we needed to refactor was using ORM (Hibernate) and we shied away from a few classes since we wanted to avoid data migrations. Eventually we'll have to tackle the issue and we won't have a guidebook to help make better choices.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted November 12, 2002

    Refactoring: Improving the Design of Existing Code

    A little while back I was introduced to a word I had never heard before, Refactoring. I was told to get Martin Fowler's book and read it so I could gain a better understanding of what Refactoring was. Well folks, I would classify this book as a 'Hidden Treasure'. Although it is not a flashy or well known title, I believe its impact can be much deeper and long lasting than many of the mainstream, more popular technology books. The underlying theories that it teaches can be applied for years, even when languages change. There are only a couple of things I would change about this book, which I will mention below. Preface The Preface it brief enough, and gives the definition for the word Refactoring. This is a good thing because right form the start you get the true definition of Refactoring. In short, refactoring is the process of changing code to improve the internal structure, but not changing the external behavior. Chapter 1: Refactoring, a First Example In this chapter Mr. Fowler tries to start by showing a simple Refactoring example. The problem is that the chapter then goes on for 50+ pages. Mr. Fowler explains his reasons for doing this, but I think that a simple example should have been much simpler. Especially when it is in the first chapter of the book. It's not that this isn't a good chapter. I feel it's just too soon in the book. I would have put it at the end. Chapter 2: Principles of Refactoring This is an excellent chapter. The definition of Refactoring is discussed as well as the following questions: Why should you refactor? When should you refactor? What do I tell my manager? This last question may seem funny, but when you read this chapter you will understand why it is in there. This chapter also discusses common problems that occur during Refactoring, and Refactoring and performance. Chapter 3: Bad Smells in Code In this chapter things that cause code to 'smell' are discussed. When code 'smells' it could be an indicator that refactoring is needed. 22 different 'smells' are discussed. My favorites were Duplicated Code, Large Class, and Lazy Class. This is a chapter full of awesome hints. Chapter 4: Building Tests Building tests is an important part refactoring. Refactoring is done in small steps, and after every step you should test. In this chapter the discussion covers the processes and methodology of applying tests during refactoring. Chapter 5: Toward a Catalog of Refactorings This chapter is a quick setup for chapters 6 to 12. Mr. Fowler explains his method for cataloging the individual refactorings. What is pretty amazing is that he has taken a lot of time naming and detailing each refactoring. Chapter 6: Composing Methods One of my favorite chapters. Mr. Fowler opens by saying, "A large part of my refactoring is composing methods to package code properly." This chapter is all about that. 9 total refactorings are explained. My favorite ones are Inline Method and Extract Method. Chapter 7: Moving Features Between Objects Sometimes you need to move things from one object to another. This chapter discusses the art of moving features between objects. 8 total refactorings are discussed and detailed. My favorite from this chapter is Extract Class. Chapter 8: Organizing Data A very large chapter that discusses in meticulous detail 16 refactorings that will make it much easier to work with data. One thing that becomes very obvious in this chapter is that certain refactorings can go either way. What I mean is illustrated by these two: Change Value to Reference and Change Reference to Value. So some refactorings are not just one way deals. It just depends on the situation. Chapter 9: Simplifying Conditional Expressions This is a very useful chapter since conditional logic is a common occurrence in the programming world. Because conditional logic has a tendency to get very complex, this chapter has 8 refact

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted June 13, 2011

    No text was provided for this review.

  • Anonymous

    Posted October 31, 2008

    No text was provided for this review.

  • Anonymous

    Posted October 2, 2009

    No text was provided for this review.

  • Anonymous

    Posted January 3, 2011

    No text was provided for this review.

  • Anonymous

    Posted July 1, 2010

    No text was provided for this review.

Sort by: Showing all of 8 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)