Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series) Hardcover – 23 July 1999
There is a newer edition of this item:
Frequently bought together
Besides an introduction to what refactoring is, this handbook provides a catalogue 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 "smells" of bad code, readers get to the heart of the book, its catalogue of more than 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 Back Cover
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.
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
The Kindle Storyteller contest celebrates the best of independent publishing. The contest is open for entries between 1st May and 31st August 2021.
Discover the Kindle Storyteller 2021
- Publisher : Addison-Wesley; 1st edition (23 July 1999)
- Language : English
- Hardcover : 431 pages
- ISBN-10 : 0201485672
- ISBN-13 : 978-0201485677
- Dimensions : 2.54 x 19.05 x 23.5 cm
- Best Sellers Rank: 62,018 in Books (See Top 100 in Books)
- Customer reviews:
Top reviews from United Kingdom
There was a problem filtering reviews right now. Please try again later.
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.