Scan barcode
A review by rodhilton
Refactoring to Patterns by Joshua Kerievsky, Martin Fowler, Ralph Johnson
3.0
Refactoring to Patterns essentially attempts to merge together two types of books: books on code design (such as the GoF Patterns book, Head First Design Patterns, Patterns of Enterprise Application Architecture, etc) and books on engineering principles (such as the eXtreme Programming series and, most of all, Fowler's Refactoring).
In this, it succeeds. Refactoring to Patterns really makes explicit the relationship between agile programming practices and OO design. It draws a connection precisely where two concepts are connected but where few books tread. Kerievsky isn't a Patternista either, he makes it clear that Patterns are often overkill for some types of problems, and he always mentions both the benefits and costs of a pattern being discussed.
The main problem with the book is that it exists to create a connection that I think most people can create on their own. If you've read Refactoring and a Design Patterns book, I don't think there's a lot to be gained here. Often I found myself reading the writeup of a pattern, looking at its diagram, and skimming the "How To" section. I'd often skip the example entirely, as it was clear by that point that I knew exactly how to refactor to a pattern.
The book claims that its goal is to make it clear not just HOW to implement a pattern (which GoF does a great job of), but WHY. What does the code look like when it's in a state that it should be refactored to a design pattern? Kerievsky does a decent job with this goal, but often I wondered if it would have been better for him to go into more examples and detail on that subject, and spend less time taking the reader step-by-step through the actual refactoring itself. Those pages often felt like padding in a book struggling to reach 300 pages.
If you feel comfortable implementing Design Patterns but unsure of when it's appropriate to use them, this would be a good book, though I have a hard time believing there isn't a better one out there (though to be fair, I can't think of one). Otherwise, I don't think there's much to glean from the book - often pages were spent spelling out refactoring steps that anyone with some experience with Patterns probably already understands.
In this, it succeeds. Refactoring to Patterns really makes explicit the relationship between agile programming practices and OO design. It draws a connection precisely where two concepts are connected but where few books tread. Kerievsky isn't a Patternista either, he makes it clear that Patterns are often overkill for some types of problems, and he always mentions both the benefits and costs of a pattern being discussed.
The main problem with the book is that it exists to create a connection that I think most people can create on their own. If you've read Refactoring and a Design Patterns book, I don't think there's a lot to be gained here. Often I found myself reading the writeup of a pattern, looking at its diagram, and skimming the "How To" section. I'd often skip the example entirely, as it was clear by that point that I knew exactly how to refactor to a pattern.
The book claims that its goal is to make it clear not just HOW to implement a pattern (which GoF does a great job of), but WHY. What does the code look like when it's in a state that it should be refactored to a design pattern? Kerievsky does a decent job with this goal, but often I wondered if it would have been better for him to go into more examples and detail on that subject, and spend less time taking the reader step-by-step through the actual refactoring itself. Those pages often felt like padding in a book struggling to reach 300 pages.
If you feel comfortable implementing Design Patterns but unsure of when it's appropriate to use them, this would be a good book, though I have a hard time believing there isn't a better one out there (though to be fair, I can't think of one). Otherwise, I don't think there's much to glean from the book - often pages were spent spelling out refactoring steps that anyone with some experience with Patterns probably already understands.