Book review by Ted Felix
This book presents a set of refactorings that transform code from one design to another. If you've done object oriented programming for a while, you are probably familiar with the concept of "factoring out code" into a base (or super) class. That goes by the name "Pull Up Method (322)" in this book.
The refactorings range from the ultra-simple "Rename Method (273)" to the potentially ultra-complex "Convert Procedural Design to Objects (368)". Most of these refactorings are normal everyday occurrences. What Fowler brings to the table is a series of small steps for each of the refactorings that makes them easy and safe to do. This helps reduce the fear involved in modifying working code. The stepwise approach also inspires the reader to come up with their own refactorings and detail the steps using some of the tricks presented in this book.
I found the most value in the steps themselves. There were some small changes that I had never considered that make the transformation of code easier and safer. I also found some new ways to look at code from some of the more interesting refactorings. This made the book worthwhile for me.
Good programming habits are presented as refactorings. Much of this info is already covered in McConnell's Code Complete, but here you see how to gently move bad code toward good code. Introduce Assertion (267) and Replace Magic Number with Symbolic Constant (204) are good examples of common-sense programming advice ("use assertions" and "no hard-coded numbers").
You won't find a "convert lousy C++ written with all global objects and static functions to good object oriented code" or a "remove gotos" or even a "fix code that was written by an Electrical Engineer who prefers Forth" refactoring. Although toward the back, they do present sketches of some big refactorings like Convert Procedural Design to Objects (368). Given the ideas in the book, you should be able to create your own refactorings suited to whatever task you need to accomplish.
I noted only a few minor flaws that don't detract from the value of the book. However, knowledge of these flaws prior to reading will help reduce the frustration level.
I didn't like the fact that for some of the refactorings, the final code wasn't presented in its entirety. It was a bit hard to keep a running version of the code in my head so that I could see the outcome of some of the more complex refactorings. This combined with my lack of knowledge of Java did cause trouble once or twice. UML is used on the more complex examples, but UML falls short since all aspects of the refactoring can't be shown on one diagram. For some refactorings, UML combined with good discussion works very well. For others, the text doesn't make up for the weaknesses of UML.
On your first read of the book, you will be tripped up by the fact that the Mechanics section for each refactoring comes before the Examples section. The Mechanics section contains words that will make little sense until you have digested the Examples. As a reference, this is the right way to organize the book, but on your first read, you have to be careful to avoid frustration. Read the Examples first, then the Mechanics section to make sure you understood the Examples.
Chapter 3 "Bad Smells in Code" should come after chapter 12. Chapter 3 makes no sense without an understanding of the refactorings that can be used to solve these "bad smells".
This is a Java book. I'm a C++ programmer. That is important as some of the refactorings are Java-only and related to the peculiarities of parameter passing, enums, and other features of Java. If you are a C++ programmer like me, you may be confused in places. The author does take care to mention when Java-unique features are involved. It would be nice to have a C++ version, though, with some C++-specific refactorings. Maybe ones to handle the various issues discussed in Effective C++.
The Replace Type Code series of refactorings was intriguing. I need to spend a little more time with them to understand their impact. I think they may be Java-specific in that the version of Java that was around when this book was written had no "enum" type. Integer constants were used instead, and these are not type-safe at all. These Replace Type Code refactorings seem to be designed to deal with this limitation of the earlier versions of Java.
Much of the code I write for a living is interactive. So, whenever I see mention of Model-View-Controller (MVC), Presentation Abstraction Control (PAC), Entity Interface Control, n-tier architecures, Document/View and the like, I pay close attention. I'm always hoping to find something that will make my life easier.
One small refactoring (Duplicate Observed Data (189)) and two big refactorings (Tease Apart Inheritence (362) and Separate Domain from Presentation (370)) show how to move code toward a Document/View design. These refactorings place all the behavior and data into a "domain" class, and keep the UI code in a separate "presentation" class. To keep the UI up-to-date, an "observer" mechanism (publish/subscribe) is used to let the presentation class know when the underlying domain object has changed. Data is actually duplicated in the examples between the Presentation object and the Domain object. This might be a Java-ism.
After reading this, I'm considering doing further research into Presentation Abstraction Control et al. and assembling a survey article that compares all the various flavors of this design pattern. Maybe with some examples in C++/MFC. That will be unique in this day and age of Java.
Beginners/Intermediates: Once you've read McConnell's Code Complete, Larman's Applying UML and Patterns, and a book on programming in your language of choice, you should read this book. Highly recommended.
Experts: We do this every day, and we've pretty much seen it all before. But. The nice thing here is the stepwise discipline. It inspired me to think more deeply about how I divide and conquer. It also gave me some tools to make dealing with large amounts of bad code a little easier. At the very least, this book will make you think more critically about code and alternative designs for code. That's a good exercise in itself. Plus, this is considered an important book, so you have to at least have an opinion about it. Recommended.
Read from 3/6/06 to 3/18/06.
<- Back to my software books page.
Copyright ©2006, Ted Felix. Disclaimer