80 of 84 people found the following review helpful
A book I've been waiting for,
Verified Purchase(What's this?)
This review is from: Refactoring to Patterns (Hardcover)
Kerievsky has done it. He has started to pull together anti-patterns (a.k.a. "bad smells"), refactorings, and patterns into one unified study. All three work well individually. Together, they make a powerful combination.
This isn't as rigorously analytic as the original Design Patterns book. I fully expect more theory-oriented writers to follow the trail blazed here. Instead, Kerievsky gives worked examples, in great detail. At every point, he starts with a code sample drawn from real life, complex enough to be interesting. Then, step by step, he shows the incremental changes made to transition from it's problematic start to its pattern-based end point. Experienced programmers may find this plodding and repetitive. Beginners, however, often have a hard time planning incremental changes and executing them. The author takes care to keep the code in working order at each increment, showing a clear path through the forest of possibilities. Some readers may even trace the path backwards, giving another look at how each change moves toward the end state. The worked examples are the real strength of this text.
This is a book for the software maintainer. In other words, it addresses 90% or 99% of the work that real programmers do. Just about every other software text on the market assumes that the project just started - the disks are empty and the compiler shrink-wrap is on the floor. I admit, that kind of programming is the most fun. It's just not realistic, though. Most work is rework, the kind demonstrated here.
Another great feature of this book is what it lacks: dogmatic harangues about methodology. It even keeps a skeptical attitude towards patterns, since heavyweight design techniques aren't always right for lightweight problems. Kerievsky mentions agile-ism, but doesn't make it a part of the process. He does, however, take the continuous testing idea from the eXtremists and work that into the demonstrations. Bravo! Hardware designers may wonder what the fuss is about, since thorough testing has been part of their culture for years. It's a happy novelty in much of the software world, though, and deserves to become standard practice.
My only problem with this book is that there isn't more of it. For example, constructor chaining is a great idea. There are two kind of chain, though. He shows the increasing parameter list, where simpler constructors supply default values for the more ones with more parameters. It's also possible to chain in decreasing order, where each constructor processes one parameter and passes on the simplified list. (What's good for constructors, of course, is also good for other collections of related methods.)
The book's ideal reader understands an OO language, uses subclassing regularly, and knows something about design patterns. That reader, with enough patience to follow the examples, will learn a lot. More experienced developers won't need the step by step approach, but may benefit from seeing multiple refactorings working together to solve a complex problem. It has my highest recommendation for any developer who really thinks about design and redesign.