Preface

What Is Refactoring?

Refactoring is the art of improving the design of existing code. Refactoring provides us with ways to recognize problematic code and gives us recipes for improving it.

What Are the Goals of This Book?

This book is a workbook designed to help you

• Practice recognizing the most important smells (i.e., problems)

• Apply the most important refactoring techniques

• Think more about how to create great code

• Have fun!

To a smaller extent, this book is a reference book with

• A smell finder inside the covers

• A standard format for describing smells

• An appendix listing Java tools supporting refactoring

• An appendix showing key refactorings

Who Is This Book For?

Refactoring being a technique for code, this book then is especially intended for practicing programmers who write and maintain code.

Students can also benefit from refactoring, although I'd expect they'd see the value only after they've had a chance to develop medium-sized or larger programs or had to work in teams (this probably applies to juniors, seniors, and graduate students).

What Background Do You Need?

It would be helpful to have the book, Refactoring: Improving the Design of Existing Code, by Martin Fowler et al. (or at least to have access to the www.refactoring.com Web site) for its catalog of refactorings. (You can read my book and Refactoring at the same time.) Martin and his colleagues have worked out step-by-step instructions for many refactorings, and I will not repeat those in this book. Furthermore, they've provided a fully worked-out example, along with a lot of good discussion and background material. Someone determined to get through this book without that one could probably do it, but I wouldn't recommend it.

The examples in this book are written in Java. This is not because it's the easiest language to refactor, but because it's popular, and the best Java development environments provide automated refactoring support. A C# or C++ programmer has enough reading knowledge of Java to make sense of most of the questions. However, in later parts of the book, you will modify, test, and run larger programs, and this could be problematic for programmers using languages other than Java.

The book Design Patterns, by Gamma et al., describes patterns as “targets for refactoring.” It would be helpful to have some familiarity with the ideas in that book because I freely refer to the patterns it mentions. If you're not yet familiar with Design Patterns, let me recommend Steve Metsker's book, Design Patterns Java Workbook, as well.

How to Use This Book

Solving a problem is more challenging than recognizing a solution. There are answers to some problems in the back of the book, but you'll learn more if you try the problems before peeking at the answers. If you work through the problems, you'll probably even find that you disagree with me on some answers. That will be more fun for all of us than if you just look at my answers and nod.

I think it's more fun to work with others (either a partner or in a small group), but I recognize that isn't always possible.

The later (longer) examples need to be done at a computer. Looking for problems, and figuring out how to solve them, is different when you're looking at a program in your environment.

Can I Contact the Author?

Sure: William.Wake@acm.org.

I have a Web site as well: www.xp123.com. Its focus is extreme programming (XP), and refactoring is an important part of that. Refactoring (and this book) has its own corner: www.xp123.com/rwb.

I'm interested in your experience with these exercises, as well as with refactoring in general, so please feel free to write.

Acknowledgments

One of the challenges of writing a book is that it's hard to effectively acknowledge the many people who have helped you. You know you're forgetting names, and you know that the book could be even better if only you could take all of their advice.

Many people offered advice on various drafts of or exercises in this book, including Philippe Antras, Ron Crocker, Sven Gorts, Harris Kirk, Tom Kubit, Paul Michali (who provided one of the examples), Edmund Schweppe, Steve Wake, Robert Wenner, and others I know I've omitted. Sven Gorts and Tom Kubit get special mention, as they both gave me particularly extensive feedback and advice. Ann Anderson, Ken Auer, and Don Wells reviewed the manuscript for the publisher.

My programmer friends at Gene Codes Corporation (working for Howard Cash) worried that anything they did would become fodder for another example. (Their code isn't in here, but they all helped me think about what I was trying to communicate, and each gave me advice on at least some examples.) Thanks to Lucy Hadden, Jonathan Hoyle, Anna Khizhnyak, Tom Kubit, Greg Poth, and Dave Relyea.

This book owes obvious debt to the prior work of Martin Fowler and Kent Beck. Their encouragement has been as important. The format of the book is inspired by Steve Metsker's Design Patterns Java Workbook; discussions with him have been very helpful.

At Addison-Wesley/Prentice Hall, I need to thank Mike Hendrickson, Ross Venables, Anne Garcia, Michelle Vincenti, and especially my editor, Paul Petralia. Don MacLaren and Ruth Frick of BooksCraft improved the text considerably. There are many others who put a lot of work into turning the manuscript into a book; I don't know their names, but I appreciate what they do.

Pearson allowed me to use information from other books:

• Beck, EXTREME PROGRAMMING EXPLAINED: EMBRACING CHANGE, page 57, © 2000 by Kent Beck. Reprinted by permission of Pearson Education, Inc. Publishing as Pearson Addison Wesley.

• Fowler, REFACTORING: IMPROVING THE DESIGN OF EXISTING CODE, inside front cover (List of Refactorings); inside back cover (Smell-Common Refactorings), © 1999 by Addison Wesley Longman, Inc. Reprinted by permission of Pearson Education, Inc. Publishing as Pearson Addison Wesley.

• Gamma/Helm/Johnson/Vlissides, DESIGN PATTERNS: ELEMENTS OF REUSABLE OBJECT-ORIENTED SOFTWARE, pp. viii and ix (patterns list from the Table of Contents) © 1995 by Addison-Wesley Publishing Company. Reprinted by permission of Pearson Education, Inc. Publishing as Pearson Addison Wesley.

• Wake, EXTREME PROGRAMMING EXPLORED, pp.24–25, © 2002 Pearson Education, Inc. Reprinted by permission of Pearson Education, Inc. Publishing as Pearson Addison Wesley.

Finally, no acknowledgment would be complete without thanking my family. They don't just tolerate my writing, but give me encouragement, support, and love. Who could ask for more?