Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)

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.

Product Description
Refactoring is about improving the design of existing code. It 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. With refactoring you can even take a bad design and rework it into a good one. This book offers a thorough discussion of the principles of refactoring, including where to spot opportunities for refactoring, and how to set up the required tests. There is also a catalog of more than 40 proven refactorings with details as to when and why to use the refactoring, step by step instructions for implementing it, and an example illustrating how it works The book is written using Java as its principle language, but the ideas are applicable to any OO language.

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
refactorings that will help you simplify things.

Chapter 10: Making Method Calls Simpler
The 15 refactorings in this chapter help teach us how to make method calls easier to deal with.
They range from the very simple Rename Method to the more complex Replace Constructor with
Factory Method.

Chapter 11: Dealing with Generalization
Here are 12 refactorings dealing with the situations that arise from generalization. Inheritance,
Delegation, and Interfaces are some of the topics discussed.

Chapter 12: Big Refactorings
Kent Beck co-wrote this chapter with Mr. Fowler. They discuss what they call the 4 Big
Refactorings: Tease Apart Inheritance, Convert Procedural Design to Objects, Separate Domain
from Presentation, and Extract Hierarchy. These refactorings are of a more all-encompassing
type than the smaller individual refactorings from the preceding chapters. The co-authors do a
great job at putting in a nutshell what would normally take very long explanations.

Chapter 13: Refactoring, Reuse, and Reality
William Opdyke writes this chapter. He discusses his experiences with refactoring as well as
other subjects like why developers are reluctant to refactor and reducing the overhead of
refactoring. This chapter is an excellent 'putting it all together' chapter, and really helps put into
perspective the ideas that the book teaches.

Chapter 14: Refactoring Tools
Don Roberts and John Brant co-author this chapter. They discuss, as the chapter title would
indicate, refactoring tools.

Chapter 15: Putting It All Together
Kent Beck gives a quick 4-page wrap up.

One other thing I would change about the book is that I would want there to be examples in other
languages besides Java. I have practically no Java skills. For me the book would have been an
easier and faster read if it would have had examples in VB.net. Fortunately I understand enough
to get the idea of what is being taught, and that is the most important point.

Well as I said above, this book is really what I would consider a 'hidden treasure'. The things
discussed will help many people write better, more understandable code for years to come. I
would give it a 9.5 out of 10. It is well worth the {price}


Don't just read it - buy it   July 19, 2000
D. D. G. MOTH (Sussex, England, UK)
31 out of 33 found this review helpful

One can read good books on a specific technology (COM, UML etc) or on specific programming languages or even on different approaches to software development (RUP, OPEN etc) but every now and then a true classic comes along. Like Design Patterns 4 years ago now refactoring comes along. Every serious OO developer should own both of these books. Get your hands on Refactoring if only to read chapter 3, which summarises all the 'bad smells' that may creep into code. 21 generic examples of what is bad programming and why. The remainder of the book describes numerous techniques (refactorings) for changing existing code in order to remove the 'smell'. Most refactorings are accompanied with some UML, which should be enough to get the idea, and they are then further described in Java. What makes this great a book is that it can be used as a reference very easily since its design was well thought out for this purpose with a comprehensive index and tables matching smells and respective refactorings. If any of this rings a bell to CODE COMPLETE readers it should cause the ideas are very similar but very much updated here. Fowler's writing style makes once again for easy, pleasant reading. Unreservedly recommended.


Don't wait as long as I did   May 14, 2003
David C. Veeneman (Lincolnshire, IL USA)
18 out of 18 found this review helpful

I've known about this book for over a year. Initially, I thought it was about re-engineering legacy systems. I don't do that, so I didn't give it much thought. Over the past year, I have stumbled across repeated references to this book. Everyone seems to cite it, and now I understand why.

It's very easy to fall into 'analysis paralysis' when doing object design. A commonly heard complaint is "I have created 27 different class diagrams, and 42 separate sequence diagrams, but I can't seem to get any code written..." XP's popularity is due, in part, becuase it get's you into action--you begin writing code immediately, instead of creating diagrams for weeks (or months) on end. XP's motto could be "just do it!"

But how does one reconcile this "code first, ask questions later" mentality with an acknowledged need to at least do some design work? In "Refactoring", Martin Fowler provides the answer. His prescription is to create some code to get something working, then look at the code to see how it might be improved-- refactor it.

In Fowler's view, you won't really understand the problem until you have coded it, so instead of spending the next three weeks trying to find the perfect pattern for your next task, forget the pattern, and get some code going. Once you've got something workable, then think about patterns you might back into from your existing code.

Of course, that's a gross oversimplification of the process, but it gives a flavor of the ready-fire-aim process that 'Refactoring' is built around. And it seems to work--even people who don't buy into other core practices of XP seem to have adopted refactoring as a central element in their process.

The catalog of refactorings that the books provides are a first class reference on how to clean up particular problems. But to me, the most valuable part of the book is its first fifty pages.

Fowler starts the book with a simple, but ugly, example, that he proceeds to refactor, step-by-step, into something rather elegant. If you like to learn principles first, you might want to read the second chapter before going through the example, but I found it a very valuable exercise. I recommend coding the example in your language of choice, then refactoring along with Fowler as you work through the example.

There is a temptation to relegate refactoring, like testing, to simply another development technique. But like testing, refactoring is at the core of a development philosophy: "I know I'm not going to get it right on my first pass, so I'll be satisfied with making it as right as I can. Having done that, I'll have a much better idea how to make it better, and I will. But time's a' wasting, so I need to get moving."

This philosophy of continuous improvement allows the developer to get into action fairly quickly, and it reduces the risk of failure-by-delay. Fowler's book is a top-notch resource that will help the developer create more flexible code more quickly. I can recommend 'Refactoring' without reservation.


Should be part of every developer's toolkit   July 29, 1999
16 out of 16 found this review helpful

I spent seven years in the Smalltalk environment figuring (parts) of this stuff out for myself. You don't have to - buy Martin's book and shave at least a few years off the learning curve.

Refactoring is an indispensable part of software development. Like it or not, whatever you write today will be "wrong" sometime in the future. You need to have techniques for transitioning to the "right" stuff. Refactoring provides you with a wealth of small tools that can make the transition easier.

Not only that, having confidence that you can refactor your code later (supported by relentless testing) actually relieves some of the pressure you feel when you write the code the first time. Get it working, then get it right. Don't panic. Don't sweat. Enjoy your work like you did when you started (remember?). Let Refactoring guide the way.

A practical guide for any OO developer, no matter what language you are working in, though you need enough familiarity with Java to read the examples.


At least as important as Design Patterns. Buy it now.   July 20, 1999
Michael D. Hill (Virginia)
11 out of 11 found this review helpful

It's a rare book that causes the reader to say: "This changes *everything*." The Design Patterns book is one such, Refactoring is another.

The introductory chapters establish a clear theoretical and practical basis for the catalog of refactorings that make up the larger part of the text. Many of the examples are trivial, but then, many of the refactorings occur in simple situations. The more complex refactorings are usually accompanied by detailed example code. The mechanics section in each refactoring is an outstanding tool, and I expect to use it quite frequently.

I have followed the 'extreme programming' (XP) movement for some time, and I'm an ardent fan, as is, so I gather, Fowler himself. But don't be fooled by this: the book is not just for the XP crowd. All programmers who use Java (or have used more than one other oo language), will find this book a huge resource. I have a library that I recommend to journey-folk who aspire to mastery. Refactoring is certainly the newest addition. I think this book will be an instant classic.

I cannot say enough. Why not buy it now?