What do you think?
Rate this book
Martin Fowler Signature Book
Refactoring to Patterns
In 1994, "Design Patterns" changed the landscape of object-oriented development by introducing classic solutions to recurring design problems. In 1999, "Refactoring" revolutionized design by introducing an effective process for improving code. With the highly anticipated " Refactoring to Patterns ," Joshua Kerievsky has changed our approach to design by forever uniting patterns with the evolutionary process of refactoring.
This book introduces the theory and practice of pattern-directed refactorings: sequences of low-level refactorings that allow designers to safely move designs to, towards, or away from pattern implementations. Using code from real-world projects, Kerievsky documents the thinking and steps underlying over two dozen pattern-based design transformations. Along the way he offers insights into pattern differences and how to implement patterns in the simplest possible ways.
Coverage includes: A catalog of twenty-seven pattern-directed refactorings, featuring real-world code examples Descriptions of twelve design smells that indicate the need for this book s refactorings General information and new insights about patterns and refactoringDetailed implementation mechanics: how low-level refactorings are combined to implement high-level patterns Multiple ways to implement the same pattern and when to use each Practical ways to get started even if you have little experience with patterns or refactoring
"Refactoring to Patterns" reflects three years of refinement and the insights of more than sixty software engineering thought leaders in the global patterns, refactoring, and agile development communities. Whether you re focused on legacy or greenfield development, this book will make you a better software designer by helping you learn how to make important design changes safely and effectively.
"
This book introduces the theory and practice of pattern-directed refactorings: sequences of low-level refactorings that allow designers to safely move designs to, towards, or away from pattern implementations. Using code from real-world projects, Kerievsky documents the thinking and steps underlying over two dozen pattern-based design transformations. Along the way he offers insights into pattern differences and how to implement patterns in the simplest possible ways.
Coverage includes: A catalog of twenty-seven pattern-directed refactorings, featuring real-world code examples Descriptions of twelve design smells that indicate the need for this book s refactorings General information and new insights about patterns and refactoringDetailed implementation mechanics: how low-level refactorings are combined to implement high-level patterns Multiple ways to implement the same pattern and when to use each Practical ways to get started even if you have little experience with patterns or refactoring
"Refactoring to Patterns" reflects three years of refinement and the insights of more than sixty software engineering thought leaders in the global patterns, refactoring, and agile development communities. Whether you re focused on legacy or greenfield development, this book will make you a better software designer by helping you learn how to make important design changes safely and effectively.
"
400 pages, Hardcover
First published January 1, 2004
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 48 reviews
September 30, 2011
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.
May 30, 2021
I bought and read this book to see if I could recommend it to some of the people I occasionally consult. Yes, I can.
On the other hand, I didn't expect to get much out of it myself, and I didn't.
It assumes that you've already read and grokked Design Patterns and Refactoring. As the title implies, it tells you how refactor to patterns, in case you can't connect those dots yourself.
It's all very sensible and appropriate, but I learned nothing I hadn't already figured out for myself.
On the other hand, I didn't expect to get much out of it myself, and I didn't.
It assumes that you've already read and grokked Design Patterns and Refactoring. As the title implies, it tells you how refactor to patterns, in case you can't connect those dots yourself.
It's all very sensible and appropriate, but I learned nothing I hadn't already figured out for myself.
January 30, 2014
Without context advises from pattern books like Design Patterns: Elements of Reusable Object-Oriented Software can be difficult to apply. This is where Joshua's book shine. He walks through many different patterns, shows how messy code could look and explains how to refactor the code into patterns.
Most importantly he also gives many advises to when not to apply the refactorings. I particularly likes the boxes with pros and cons for each refactoring.
The book heavily references Design Patterns: Elements of Reusable Object-Oriented Software and Refactoring: Improving the Design of Existing Code. Although I have read both books I find it difficult to figure out which order it would be best to read the books in. But in the end all three books needs to be read multiple times to absorb all the knowledge.
The main concern I have with the book is the mechanics section that step by step explain how to apply the refactoring, right after this there is an example. I think the mechanics are almost redundant. I say almost because the section might prove usefull when using the book as a reference.
Most importantly he also gives many advises to when not to apply the refactorings. I particularly likes the boxes with pros and cons for each refactoring.
The book heavily references Design Patterns: Elements of Reusable Object-Oriented Software and Refactoring: Improving the Design of Existing Code. Although I have read both books I find it difficult to figure out which order it would be best to read the books in. But in the end all three books needs to be read multiple times to absorb all the knowledge.
The main concern I have with the book is the mechanics section that step by step explain how to apply the refactoring, right after this there is an example. I think the mechanics are almost redundant. I say almost because the section might prove usefull when using the book as a reference.
August 23, 2012
Like several other reviewers, this book left me scratching my head slightly and wondering what its aim really was. I was hoping the focus would be more on analysis of legacy code, with advice on discovering and teasing out potential patterns. Instead, this is almost entirely a "how-to" book.
The vast majority of its 350 pages are taken up with 27 refactorings. Each refactoring includes a "how to" section and then an (often lengthy) step-by-step example. Yet, if you're familiar with design patterns and refactorings, both sections could be significantly shorter.
Only about 50 pages are devoted to the when-and-why of refactoring, and I found the advice there to be fairly generic.
It's not a bad book; as programming books go it's pretty well written and mostly manages to avoid coming off as dry and academic despite its subject matter. But I just don't think it really adds much to the literature on either refactorings or design patterns.
The vast majority of its 350 pages are taken up with 27 refactorings. Each refactoring includes a "how to" section and then an (often lengthy) step-by-step example. Yet, if you're familiar with design patterns and refactorings, both sections could be significantly shorter.
Only about 50 pages are devoted to the when-and-why of refactoring, and I found the advice there to be fairly generic.
It's not a bad book; as programming books go it's pretty well written and mostly manages to avoid coming off as dry and academic despite its subject matter. But I just don't think it really adds much to the literature on either refactorings or design patterns.
January 12, 2019
A solid resource for software developers. Essentially, it provides a detailed and prolonged practical look at the broader context that is often missing in typical design pattern/GoF type books. There is a lot of real code and explanation here. And the code displayed generally isn't some sort of pared down or contrived example. My only beef is that I found some aspects of the layout to be rather tedious, and while initially the format seems attractive and effective, by the end it seems too busy and perhaps even grating due to repetition.
January 16, 2018
Really useful reference material. You need to be comfortable with design patterns in order to fully appreciate the message of this book. The mechanics for each type of refactoring is refreshing as we're often introduced to design patterns or refactoring from a singular example. This book bridges the gap between an existing solution to one that uses design patterns.
November 3, 2021
Refactoring and design patterns are all fascinating in the world of programming on their own, and now that they are put together in one book, it makes reading the book even more engaging.
The book describes the favorable conditions for refactoring so that you can identify the pattern, then explains the refactoring method step by step, and finally applies it to a piece of code from a real application. The output of your work is a refactored code that follows one of the design patterns.
Book is so informative and inspirational and give you good ideas for refactoring and using design patterns.
The book describes the favorable conditions for refactoring so that you can identify the pattern, then explains the refactoring method step by step, and finally applies it to a piece of code from a real application. The output of your work is a refactored code that follows one of the design patterns.
Book is so informative and inspirational and give you good ideas for refactoring and using design patterns.
October 16, 2013
Personally I expect more the book, nevertheless it gave me quite an impression. The book gave a lot of code example but unfortunately some of them is unclear, which need me to stare at the code several minutes till I understand the author intention. Good book a software engineer who want to know design pattern deeper, but i don't recommend this book for beginner.
October 10, 2019
Great and useful book. Highly recommended.
August 31, 2018
This should for sure be your first book about patterns. I really enjoyed the approach in this book, it is very well explained. Joshua Kerievsky first shows the problem and then refactors the code step by step into a pattern. Why did I enjoy the approach? Because giving you a pattern catalog and just going over patterns isn’t enough. You need to understand when to use patterns and not to use it prematurely, maybe you won’t even need it. When you see the “bad” code and you take steps to refactor it into a pattern you start appreciating that pattern more.
August 29, 2018
The book drives you into the world of patterns in a very didactic way. Easy to read, engages you to use the patterns and also, very important, when not to use it. Full of stories and real examples, it shows you the decision process to when to use a pettern or another, or not use it at all. Not using patterns is an enemy, overengineering is an enemy as well.
April 28, 2022
I liked introductory chapters talking about attitute to refactoring & patterns. But detailed mechanics description for refactorings seemed too boring. Also many patterns were left in the shadows.
Perhaps i may recommend to read this book, especially concrete refactorings before reading GOF or other patterns books.
Perhaps i may recommend to read this book, especially concrete refactorings before reading GOF or other patterns books.
March 21, 2023
Very good book which is for me a level 2 after Martin Fowler’s refactoring.
It is very similar as it provides theory followed by a catalog of refactorings.
The code smells, refactorings and design patterns are clearly explained and the examples are powerful ways to understand them in Java.
However, even more than the refactoring book, many refactorings only apply to OOP… hence the 4 stars.
It is very similar as it provides theory followed by a catalog of refactorings.
The code smells, refactorings and design patterns are clearly explained and the examples are powerful ways to understand them in Java.
However, even more than the refactoring book, many refactorings only apply to OOP… hence the 4 stars.
December 27, 2016
Refactoring is my favorite topic in Software Quality. This book has only made me an even a bigger Merciless Refactorer. I like the way Joshua put the focus on learning the problem and not the solution.
October 12, 2018
The more interesting version of "Design patterns" by GoF and a lightweight substitute of one third of "Agile software development - Patterns practices principles".
The natural continuation of Fowler's "Refactoring"
The natural continuation of Fowler's "Refactoring"
March 6, 2020
Sem dúvidas é um dos melhores livros sobre o assunto. O Autor aborda as técnicas de uma maneira mais interessante, fazendo uma divisão onde ele dá um contexto sobre o tema, um roteiro de como, onde e quando aplicar e não aplicar, seguido de uma explicação detalhada sobre os padrões.
November 6, 2017
Another book to be read again and again, after "Refactoring: Improving the Design of Existing Code"
June 15, 2018
Kerievsky provides a succinct set of patterns with non-trivial examples for each. All developers should have this for reference.
December 12, 2018
Very interesting book, but in order to get the most benefits from it, you have to read the Refactoring book by Martin Fowler first. and preferred to read the Design Patterns book by the Gang of Four.
June 25, 2019
Excellent book on refactoring and patterns. Very good examples. Always a pleasure to reread.
March 29, 2020
Bit dated, but still solid patterns to follow
February 25, 2013
This book is an excellent combination of Design Patterns and Refactoring. It's perfect if you're looking to improve your understanding of design patterns and/or refactoring, but it really shines if your goal is to understand how they both work together. Rather than thinking of design patterns as things you cook into your program, which is what usually leads to "design pattern abuse," this book recommends you start with a simple design first, and evolve to design patterns if you start noticing "code smells" that are ideally solved with them, unless you know without a doubt that you will need them.
This book is organized exactly like Refactoring, and looks very simiilar in its layout. Unlike Refactoring, this book isn't quite so useful as a cookbook of common refactorings. Its refactorings are very uncommon, but the situations that need them REALLY need them. So, as the Afterword recommends, don't try so hard to get good at these refactorings. Instead, use it to understand the thought processes that lead to those refactorings. Don't memorize this book--"grok" it.
The code samples in this book are perfect, short enough to be straightforward and concise, but real enough to not resort to "toy code." This is real-world code, and they are perfect candidates for the refactorings they are used to demonstrate. However, I wasn't so impressed with the "Mechanics" section of each refactoring. They were very hard to follow, though I'm not sure how they can be improved, so it may just be a symptom of the complex nature of many of these refactorings, rather than a reflection on the author's explanatory abilities.
This book is organized exactly like Refactoring, and looks very simiilar in its layout. Unlike Refactoring, this book isn't quite so useful as a cookbook of common refactorings. Its refactorings are very uncommon, but the situations that need them REALLY need them. So, as the Afterword recommends, don't try so hard to get good at these refactorings. Instead, use it to understand the thought processes that lead to those refactorings. Don't memorize this book--"grok" it.
The code samples in this book are perfect, short enough to be straightforward and concise, but real enough to not resort to "toy code." This is real-world code, and they are perfect candidates for the refactorings they are used to demonstrate. However, I wasn't so impressed with the "Mechanics" section of each refactoring. They were very hard to follow, though I'm not sure how they can be improved, so it may just be a symptom of the complex nature of many of these refactorings, rather than a reflection on the author's explanatory abilities.
December 15, 2009
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 Martin Fowler’s work were justified, and if you really want to get the most out of this book, you should have Refactoring and Design Patterns 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!
Want to read
October 11, 2012The subject material in this book is what separates those who think they understand the purpose and utilization of patterns, from those who realize that patterns are essential not to just the design of an application, but more importantly to its extensibility and forward maintenance. Too often as software engineers, we have seen two camps of developers: those who are new to the field and unaware of good design, and the latter are those armed and dangerous with knowledge of patterns, but use them to overengineer solutions. This book provides insights into a balance - a systematical method of "refactoring" to a pattern. Filled with a large catalog of patterns (27), and with real-world examples, Joshua Kerievsky has done a fantastic job of illustrating and explaining a pattern and it's use, compared to many previous books on the subjects of patterns, which are to say very dry-guaranteed-to-kill-your-passion at the least. Well worth a read.
August 4, 2008
In regard to design patterns, lines can be strongly drawn between developers. Some argue it is the only way to code while others believe the practice is sterile and inhibits creativity. I think patterns are useful in some situations and a hinderance in others; for me, their utility factors on a large number of variables, including project type, resources, language, and number of developers involved in the project. It helps to understand and research the technology if only to eschew or discount the position. So--I recommend this book to any developer, if only as an overview of re-factoring and design pattern usage. I recommend reading the "gang-of-four" book (Design Patterns: Elements of Reusable Object-Oriented Software) prior to reading this one, however.
December 14, 2016
If you read Refactoring, then this book will be the next step. While Martin Fowler explains in Refactoring the mechanics of the trade, Joshua Kerievsky explains how you can use the small building blocks to make significant refactorings towards patterns. Especially helpful when you need to solve problems that fall within a useful pattern and you don’t want to reinvent the wheel. The book is even better when you are at a pattern that someone forced upon your application but doesn’t solve the problem. You will profit from the parts of the book that explain refactorings away from a pattern. That is an often-overlooked aspect of the book that can bring you the most. Therefore, please read those parts as well.
March 11, 2018
This book is presented as the connection between Design Patterns [GoF] and Refactoring [Fowler]. Overall content is good and thoroughly explained. I was expecting it to have a structure like: refactoring ABC from Fowler can be matched with patterns X, Y, Z from GoF. However, it feels more like a paraphrased version of Fowler's Refactoring book, which makes it feel repetitive.
And even if my expectations would've been met, I now realise you wouldn't need a book to describe this relation between patterns and refactoring, that is, I think it's easy to figure it out on your own after thoroughly grasping both concepts individually.
And even if my expectations would've been met, I now realise you wouldn't need a book to describe this relation between patterns and refactoring, that is, I think it's easy to figure it out on your own after thoroughly grasping both concepts individually.
October 11, 2013
This book is quite dated and can be misleading. However just skimming through was helpful to understand all of existing patterns.
Some patterns are dead and considered as anti-patterns:
http://programmers.stackexchange.com/...
http://blog.ploeh.dk/2010/02/03/Servi...
If you haven't read Dependency Injection in .NET by Mark Seemann, and thinking about next book I highly recommend to close this page, and go and read right now - that book is also all about patterns and OOP.
Some patterns are dead and considered as anti-patterns:
http://programmers.stackexchange.com/...
http://blog.ploeh.dk/2010/02/03/Servi...
If you haven't read Dependency Injection in .NET by Mark Seemann, and thinking about next book I highly recommend to close this page, and go and read right now - that book is also all about patterns and OOP.
September 12, 2013
If you already have applied yourself proper TDD and refactoring, don't buy this. Almost everything in this book is totally intuitive if you know about design patterns. You don't even have to be an expert to know every single pattern driven refactoring in this book.
If you don't, I guess it is a great introduction to refactoring and design pattern, probably even better than Martin Fowler's book. Often, design pattern books are boring and unusable, but not this one.
If you don't, I guess it is a great introduction to refactoring and design pattern, probably even better than Martin Fowler's book. Often, design pattern books are boring and unusable, but not this one.
Displaying 1 - 30 of 48 reviews