Article Preview

REVIEW

Book: Refactoring

Issue: 5.2 (January/February 2007)
Author: Marc Zeedar
Article Description: No description available.
Article Length (in bytes): 7,138
Starting Page Number: 10
Article Number: 5206
Related Web Link(s):

http://www.awprofessional.com/otseries/

Full text of article...

What is refactoring, exactly? Refactoring is a systematic approach to improving existing code, either that quick-and-dirty stuff you wrote just to get something working, or a more planned-out approach that eventually ran into subtle design flaws. For those of us not trained as programmers, refactoring is an important concept we need to learn. Martin Fowler's book serves as a master-work of refactoring techniques.

First, a caveat: Refactoring is not the kind of book you can absorb quickly -- many of the concepts will take time to put into practice to truly absorb them, so I don't consider this to be a comprehensive review (I did not read every chapter). Think of it more as an overview. I'll do my best to summarize the book and indicate its general tone and nature so you can determine if it's a good fit for you.

One of the most frustrating things about programming that I run into is the conflict between design (planning) and implementation. The ideal of design is to plan a structure for your program and get a lot of the problems worked out in advance. But much of the time I either just need to get something working now or I am so unsure about my implementation that I need to experiment just to see if the project is even feasible. The result is that my initial program is horrible -- it might work, but inside it's a nightmare that's difficult to modify and seemingly impossible to expand with new features. So for my "real" version I start over from scratch with a better design.

As an amateur programmer I was surprised to discover in Refactoring that this is normal -- even pros run into this problem (albeit on a larger scale). It's almost impossible to create a perfect design without working on the implementation, and during a project there will always be unexpected issues that change the way the design should have been done. To quote from the preface, "... design, rather than occurring all up front, occurs continuously during development." That makes tons of sense to me.

I found chapter 3, "Bad Smells in Code," fascinating and helpful. It identifies about 20 specific types of coding problems, such as the "long method" -- where a method tries to do too much (ideally a process should be broken into smaller steps, making it easier to debug). If you notice any of these creeping into your code you know it's time for some refactoring.

The key to refactoring is that by using a system to improve the code you can do it without breaking your existing program. So you'll do things like move a method inside an object, or take two similar methods and merge them into a single more generic one. You must use a system to do this or you'll end up with more trouble than you started with. Refactoring is all about the specifics of this system. The bulk of the book -- chapters 5-12 -- is a collection of specific refactoring techniques to solve particular problems.

Each of these chapters focuses on a specific kind of refactoring and gives you step-by-step processes to gradually improve the code. For instance, chapter 7, "Moving Features Between Objects" is about adjusting how objects handle responsibility. Within that chapter are specific techniques like "Move Method," "Move Field," "Extract Class," "Inline Class," "Hide Delegate," "Remove Middle Man," and more. Depending on your situation you may use only one or more of these techniques.

Fowler gives tips on when to use these various techniques, such as when he finds "a method that seems to reference another object more than the object it lives on" he knows it's time to use the "Move Method" technique.

Then each technique is broken down into a series of steps. For instance, for the "Move Method" technique you copy the old method to a different class, change any code necessary to make it work within that object, and then make the old method call the new one (delegate). Thus you can test your program and ensure everything works without having to change all the old references to the original method! Once you know it's working you can decide to change other referencing code or just leave it as a delegate.

Refactoring is of course not written with REALbasic in mind -- the examples are in Java -- but I found it fairly easy to adjust the thinking to REALbasic. (Fowler explicitly stays away from Java-specific OOP techniques and keeps things broad so that they'll work with any object-oriented language.) The examples are all in addition to detailed explanations, so understanding the precise code isn't necessarily required.

Beginners who aren't used to object-oriented programming terms and techniques will have an uphill battle (brush up on your OOP first), but though the book is written with professionals in mind, I still found it understandable and learned a great deal. The structure of the book is such that some of the techniques are for esoteric problems only advanced programmers would run into so you can safely ignore parts of the book until you need them.

I was surprised at how easy the book is to read: it feels like a textbook but is written with a simple, elegant style that is not pretentious or too academic or technical.

In conclusion, if you're a professional programmer this book is a must for your library; if you're an amateur or a hobbyist Refactoring may be beyond you now, but if your projects are getting more complicated and you're running into design frustrations, I'm certain the book will be of tremendous aid to improving your code. I know I can't wait to start putting some of the techniques to work in my projects!

End of article.