I have finally gotten around to reading Martin Fowler’s Refactoring: Improving the Design of Existing Code. In fact, I’ve also just gotten around to reading the Gang of Four Design Patterns book. These two books belong on every OO programmer’s bookshelf.
Refactoring is the art of improving software. Before the Fowler book, it was almost completely art. With this book, there’s a bit more science to it. The largest section of the book is a catalog of Refactorings: systematic changes you can make to your programs to make them more reusable and easily understood.
The book starts off with introductory text that describes the point of refactoring and gives some examples to make it clear how they’re really applied. I liked the discussion of “code smells”, because I think that’s a good way to describe the feel of code that may be in need of some change.
Many of the refactorings may seem obvious if you’ve been programming a while. But, that’s part of the point: these are things that experienced programmers may do naturally. Just as the GoF cataloged the patterns that are commonly used and described how and when to use them, Fowler has taken these refactorings and made their usage explicit.
One refactoring that seems so simple but just hadn’t occurred to me before was “Null Object”. Though Java protects the programmer from stepping into memory locations they shouldn’t be, it doesn’t protect from accessing object references that are null. So, if you’re being safe in your code, you end up with all sorts of if (foo == null) lines in your code. The Null Object refactoring introduces an object that provides a safe value to work with. This is particularly useful when it comes to JSPs or other templates: your null object could provide default values for those particular fields. Certainly, these values appearing still represent some kind of error condition, but at least you can be sure that the user will get a nicer looking page from your webapp than a “500 Servlet Exception” with an icky traceback.
One added bonus to the Refactoring book is that IDEs like Eclipse have the ability to automatically, mechanically apply some of the refactorings for you. The names Eclipse uses for the refactorings are straight from Fowler’s book.
Design Patterns by the GoF and Refactoring by Fowler both belong on any OO programmer’s bookshelf. They provide useful terminology for solutions to common problems.
I’m hoping to soon read Fowler’s newer Patterns of Enterprise Application Architecture.