Refactoring: Improving the Design of Existing Code 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
There is a newer edition of this item:
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. 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. 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.
From the Inside Flap
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.
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.
- Publisher : Addison-Wesley Professional; 1st edition (July 1, 1999)
- Language : English
- Hardcover : 431 pages
- ISBN-10 : 0201485672
- ISBN-13 : 978-0201485677
- Item Weight : 2.05 pounds
- Dimensions : 1 x 7.5 x 9.25 inches
- Best Sellers Rank: #94,621 in Books (See Top 100 in Books)
- Customer Reviews:
About the authors
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
1. Starts with an 'anti-pattern' ... how not to write code.
2. Ends with how that should have been written.
3. Shows how to transform '1' to '2'.
'1' and '2' alone applies to all serious software developers writing systems larger than, say 1000 lines.
The book gives the impression that '1' occur only after code is modified multiple times. But after working 25yrs in multiple companies / teams, I know that these mistakes are is very common in many greenfield projects as well.
In case you aren't aware of what refactoring is, I'll give you Fowlers definition.
"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." For the most part this means cleaning up your existing - yet working - code. It involves anything from renaming a method to be more concise with the purpose of that method, to breaking up switch statements into a polymorphic structure. There are many different techniques used to refactor your code, which is what you learn in this book.
Right off the bat Fowler throws you into a small sample application that is poorly designed. He then takes you through a few different refactoring techniques that improve the design of this simple application. Right from the start you see how effective refactoring can be. From there he goes into topics such as how to detect "bad smells" in code. This chapter is particularly informative and entertaining. You also learn a little bit about testing. After the introductory chapters you begin to dig into a deep catalog of refactorings. Each one is named. Like design patterns - naming the refactoring and building a vocabulary really helps in communicating thoughts and ideas.
The catalog of refactorings is extremely useful. They are structured so that each refactoring has a name, a motivation, the mechanics and a simple example. This is very effective. As I said earlier, the name is useful because it helps build your programming vocabulary and it helps in communicating thoughts and ideas. The motivation explains why the refactoring should be done and when it should/shouldn't be used. The mechanics provide a step-by-step description of how to carry out the refactoring and the example shows a small example of the refactoring in use. All examples are written in Java 1.1.
Although the examples are written in Java the book is still very good for any developer. Developers that have never written a line of code in Java, C++, C#, or anything similar may have a little bit of a tougher time working through this book. Luckily most examples are very small and simple so even if you fall into this category you shouldn't have too much of a learning curve. Some of the code is a bit outdated and can be done a bit better now-a-days but what do you expect? This book was written 8+ years ago! Times have changed. The ideas are still very relevant though, which is what makes this book so timeless.
Martin Fowler books are always a joy to read. His writing style is humorous, yet often very blunt and to the point. Just like UML Distilled, he is able to communicate a lot of ideas into a very short amount of space - the book is a bit dense in other words, which is very good in my opinion. Martin Fowler does not beat around the bush and he has very strong opinions on certain topics. Unlike a lot of books you read, he actually writes with personality. I have a hard time putting his books down. Here is an example of the type of verbiage he uses...
On how comments can be a "bad smell":
"Don't worry; we aren't saying that people shouldn't write comments. In our olfactory analogy, comments aren't a bad smell; indeed they are a sweet smell. The reason we mention comments here is that comments often are used as a deodorant." - Martin Fowler. Here he is talking about how people use comments to hide bad code, or "bad smells".
I highly recommend this book. If you are a professional developer or plan on becoming one then click the "Buy Now" button without second thought. This is one of those rare books worth its weight in gold - I would spend $100.00 on a book like this if I had to.
It follows closely in the DP community's habit. For each way of improving a program, it systematically presents a name, set of conditions when it does or does not apply, and (unlike most DP books) clear, demonstrative examples and variations. As with design patterns, many of these recommendations have a sense about them of "I already knew that." That's a good thing - it means you bring familiarity to the reading, instead of starting cold. That lets Fowler get on with his real business, which is to systematize the knowledge and regularize the process of choosing a technique to use.
I hope this follows another habit of the DP community, too: the public cataloging, collecting, and sharing of new techniques for refactoring. I could add bunches to the list, as I'm sure any other seasoned programmer could. One thing is distinctive about the refactorings: the number that come in matched, opposite pairs. This just emphasizes the context dependency of refactoring - each technique has its place, but is not appropriate in all places. Also, paired opposites effectively double the number of choices a practitioner has.
Design patterns are very helpful, almost like power tools for programmers. Face it, though: initial design and implementation are only 1-10% of a large program's life. Maintenance, extension, and re-design are the other 90-99%. DP techniques get a program started, refactorings keep it going.
If you started programming before most of your co-workers were born, you may not get the most out of this book. Get it anyway, and make sure the young pups read it. This knowledge needs to be spread.
Top reviews from other countries
Till I read this I'd always refactored on the basis of performance, reflecting a prior career in hard engineering. So if I used a block of code more than once then I extracted that block as a method. Or if I used a computed value more than once in a code unit then I used a temp variable to store that value and save repeated computation. Otherwise I usually left the code as it was.
After reading the very lucid (and honestly written) first 3 chapters I will never be so simplistic again. Fowler advises refactoring even if only to improve readability of the code. But refactoring ought to also be done with object-oriented design advantages in mind, e.g. maintainability and extendability. So long lists of class attributes or method parameters are discouraged in favour of grouping in an array or agglomerates; interface differentiation preferred to sibling class creation and so on.
Fowler explains how refactoring itself does not address performance issues - in fact the refactoring process may reduce performance a bit. Neither will refactoring eliminate performance drag due to bad system architecture: system design always remains the primary way to achieve performance. But refactoring does prepare code for final optimisation in that it breaks it into its sort of natural components which can then be analysed individually. Performance issues, like so many other effects, follow a Pareto distribution: 80-90% of the drag is attributable to 10-20% of the code components. So refactoring provides a means of getting the maximum gain in system speed with the minimum of code or algorithm changes - as well as the primary benefit of readable and reusable code.
The organisation of this book is itself commendable. After easily read intro chapters, he has catalogued all minor refactorings in several subsequent chapters using UML diagrams as well as explanations. Major refactorings are presented after this. Then some actual case studies with commercial systems are covered, software tools for refactoring are discussed and a final summing-up chapter with last tips. Inside the front cover we have a convenient index of the refactorings. And inside the back cover we have an index of code smells (code items that just seem intuitively obtuse) opposite their recommended refactoring.
Many previous reviewers of this book said this stuff is already in Gang Of Four or Josh Bloch's Effective Java. Some even opine that the book is puffed out and could use some refactoring itself. This is the just the kind of response you get from dumb people after they see a solution presented to them: it sublimely ignores the fact that those same people didn't even recognise the original problem - let alone its solution. I take my hat off to Fowler for this work. Despite its age and the primitive Java version used, the essence of this work still holds true nearly 20 years on. That alone makes it a software classic.
You may notice that most of the refactorings also have a reverse refactoring somewhere in the book. I guess the art of mastering refactoring is picking the most suitable one for the code you are writing (or someone else has written).
Don't be disappointed when you first read it, if you give it time the book and Martin's style of writing will grow on you.
- text cannot be reduced in size enough. Kindle touch character size range from enormous (8 words per page) to still too big (see below).
- page breaks aren't preserved.
The paper form of the book has small sections, sometimes a single page, each of which starts on a new page. The Kindle edition doesn't preserve the layout. Single page sections from the book usually take two pages on the Kindle; even on smallest font, line-spacing and margins. Other Kindle books do not usually have such a large font size.
The first section presents a large refactoring exercise applied to a little movie rental application, which ends up producing a very elegant solution when compared with the original. This is really like the Gang of Four book in that respect, where in the first sections of their book, they present their patterns applied to an example application, to produce a very elegant design. This isn't really surprising, since I'm sure I read Martin saying that he regards GoF as the best technical book of all time.
The first sections of the book are really about advocating a fundamentally different mindset towards refactoring. They are suggesting it's not something you should do just when something is broken or in a mess, but rather on a continuous basis, taking lots of little small steps to make your codebase easier to understand. The book details that this is something you're only really free to do if you have a rigorous test suite to tell you that you haven't broken anything, so there is a section on building a test suite. Interestingly, this book pre-dates Kent Beck's TDD book by a few years, and Beck contributed a lot to the book. There is also a section pointing out 'code smells' that should motivate refactoring; quite nicely, this is summarised in a table at the back of the book, which includes which refactorings you can apply to specific code smells. I actually have to confess that I skipped the section on building the test suite, since I'm a hardcore TDD developer and am already convinced about the merits of that, and didn't feel that it was worth investing my time in.
The next several sections of the book are more reference material. Again, just like the GoF book, each of the refactorings are presented as a pattern style library. As a result, this section of the book was a little harder to get through, as all of the examples that accompany the refactoring are fairly trivial (but you can completely understand the reasoning for that), so I sometimes found my attention a little bit waning.
Post library, there are sections on larger refactorings and refactoring tools, then a pretty large guest section by William Opdyke. To be honest, I didn't really feel like I took much away from the Opdyke section. It went into a lot of detail about refactoring tools and some of the dangers associated with refactoring in C++, due to the complexity of the language. I also just skimmed the section on the tools, since these are things that are quite commonly becoming integrated into the IDE these days.
It's clear this book was highly influenced by the GoF book. However, one aspect in which I think Fowler is superior is in his writing style. It's far less verbose and actually quite funny at times, which makes the book much more enjoyable to read.
Finally, Kent Beck writes a short summary, talking about how the book is only the beginning of the refactoring journey. That resonates quite a lot, as you get the feeling while reading the book, that the real value of it is going to be in continuously coming back to it in your daily work. Trying to look out for the code smells, then consulting the reference library and summary at the back, to aid you in going about eliminating them.
It's more than a decade old, but it's still brimming with insights that continue to apply. The examples use Java, but you can clearly see the concepts apply to any object oriented language.