Scan barcode
rodhilton's review
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.
blairconrad's review
5.0
A very good book, balancing the need to present useful refactorings against the risk of alienating readers with too-complicated refactorings. The constant references to [a:Martin Fowler|25215|Martin Fowler|http://www.goodreads.com/images/nophoto/nophoto-U-50x66.jpg]’s work were justified, and if you really want to get the most out of this book, you should have [b:Refactoring|44936|Refactoring Improving the Design of Existing Code|Martin Fowler|http://photo.goodreads.com/books/1170271761s/44936.jpg|44258] and [b:Design Patterns|85009|Design Patterns Elements of Reusable Object-Oriented Software|Erich Gamma|http://photo.goodreads.com/books/1171058709s/85009.jpg|1432171] with you.
I didn’t, though, and still found it very interesting. By the end, the “mechanism” section of each refactoring was a little tough slogging, but the examples were very followable. A must-have for work, and I was considering shelling out my own money for a copy, until my wife bought me a copy for my birthday, because she loves me even though I'm a geek.
Oh, and there are two integrated bookmarks!
I didn’t, though, and still found it very interesting. By the end, the “mechanism” section of each refactoring was a little tough slogging, but the examples were very followable. A must-have for work, and I was considering shelling out my own money for a copy, until my wife bought me a copy for my birthday, because she loves me even though I'm a geek.
Oh, and there are two integrated bookmarks!
More...