What do you think?
Rate this book
Martin Fowler Signature Book
Refactoring to Patterns
What Is This Book About?
This book is about the marriage of refactoring the process of improving the design of existing code with patterns, the classic solutions to recurring design problems. Refactoring to Patterns suggests that using patterns to improve an existing design is better than using patterns early in a new design. This is true whether code is years old or minutes old. We improve designs with patterns by applying sequences of low-level design transformations, known as refactorings. What Are the Goals of This Book?
This book was written to help
Understand how to combine refactoring and patterns
Improve the design of existing code with pattern-directed refactorings
Identify areas of code in need of pattern-directed refactorings
Learn why using patterns to improve existing code is better than using patterns early in a new design
To achieve these goals, this book includes the following
A catalog of 27 refactorings
Examples based on real-world code, not the toy stuff
Pattern descriptions, including real-world pattern examples
A collection of smells (i.e., problems) that indicate the need for pattern-directed refactorings
Examples of different ways to implement the same pattern
Advice for when to refactor to, towards, or away from patterns
To help individuals or groups learn the 27 refactorings in the book, you'll find a suggested study sequence on the inside back cover of the book.
Who Should Read This Book?
This book is for object-oriented programmers engaged in or interested in improving the design of existing code. Many of these programmers use patterns and/or practice refactoring but have never implemented patterns by refactoring; others know little about refactoring and patterns and would like to learn more.
This book is useful for both greenfield development, in which you are writing a new system or feature from scratch, and legacy development, in which you are mostly maintaining a legacy system.
What Background Do You Need?
This book assumes you are familiar with design concepts like tight coupling and loose coupling as well as object-oriented concepts like inheritance, polymorphism, encapsulation, composition, interfaces, abstract and concrete classes, abstract and static methods, and so forth.
I use Java examples in this book. I find that Java tends to be easy for most object-oriented programmers to read. I've gone out of my way to not use fancy Java features, so whether you code in C++, C#, Visual Basic .NET, Python, Ruby, Smalltalk, or some other object-oriented language, you ought to be able to understand the Java code in this book.
This book is closely tied to Martin Fowler's classic book Refactoring F. It contains references to low-level refactorings, such
Extract Method
Extract Interface
Extract Superclass
Extract Subclass
Pull Up Method
Move Method
Rename Method
Refactoring also contains references to more sophisticated refactorings, such
Replace Inheritance with Delegation
Replace Conditional with Polymorphism
Replace Type Code with Subclasses
To understand the pattern-directed refactorings in this book, you don't need to know every refactoring listed above. Instead, you can follow the example code that illustrates how the listed refactorings are implemented. However, if you want to get the most out of this book, I do recommend that you have Refactoring close by your side. It's an invaluable refactoring resource, as well as a useful aid for understanding this book.
The patterns I write about come from the classic book Design Patterns DP, as well as from authors such as Kent Beck, Bobby Woolf, and myself. These are patterns that my colleagues and I have refactored to, towards, or away from on real-world projects. By learning the art of pattern-directed refactorings, you'll understand how to refactor to, towards, or away from patterns not mentioned in this book.
You don't need expert knowledge of these patterns to read this book, though some knowledge of patterns is useful. To help you understand the patterns I've written about, this book includes brief pattern summaries, UML sketches of patterns, and many example implementations of patterns. To get a more detailed understanding of the patterns, I recommend that you study this book in conjunction with the patterns literature I reference.
This book uses UML 2.0 diagrams. If you don't know UML very well, you're in good company. I know the basics. While writing this book, I kept the third edition of Fowler's UML Distilled Fowler, UD close by my side and referred to it often.
This book is about the marriage of refactoring the process of improving the design of existing code with patterns, the classic solutions to recurring design problems. Refactoring to Patterns suggests that using patterns to improve an existing design is better than using patterns early in a new design. This is true whether code is years old or minutes old. We improve designs with patterns by applying sequences of low-level design transformations, known as refactorings. What Are the Goals of This Book?
This book was written to help
Understand how to combine refactoring and patterns
Improve the design of existing code with pattern-directed refactorings
Identify areas of code in need of pattern-directed refactorings
Learn why using patterns to improve existing code is better than using patterns early in a new design
To achieve these goals, this book includes the following
A catalog of 27 refactorings
Examples based on real-world code, not the toy stuff
Pattern descriptions, including real-world pattern examples
A collection of smells (i.e., problems) that indicate the need for pattern-directed refactorings
Examples of different ways to implement the same pattern
Advice for when to refactor to, towards, or away from patterns
To help individuals or groups learn the 27 refactorings in the book, you'll find a suggested study sequence on the inside back cover of the book.
Who Should Read This Book?
This book is for object-oriented programmers engaged in or interested in improving the design of existing code. Many of these programmers use patterns and/or practice refactoring but have never implemented patterns by refactoring; others know little about refactoring and patterns and would like to learn more.
This book is useful for both greenfield development, in which you are writing a new system or feature from scratch, and legacy development, in which you are mostly maintaining a legacy system.
What Background Do You Need?
This book assumes you are familiar with design concepts like tight coupling and loose coupling as well as object-oriented concepts like inheritance, polymorphism, encapsulation, composition, interfaces, abstract and concrete classes, abstract and static methods, and so forth.
I use Java examples in this book. I find that Java tends to be easy for most object-oriented programmers to read. I've gone out of my way to not use fancy Java features, so whether you code in C++, C#, Visual Basic .NET, Python, Ruby, Smalltalk, or some other object-oriented language, you ought to be able to understand the Java code in this book.
This book is closely tied to Martin Fowler's classic book Refactoring F. It contains references to low-level refactorings, such
Extract Method
Extract Interface
Extract Superclass
Extract Subclass
Pull Up Method
Move Method
Rename Method
Refactoring also contains references to more sophisticated refactorings, such
Replace Inheritance with Delegation
Replace Conditional with Polymorphism
Replace Type Code with Subclasses
To understand the pattern-directed refactorings in this book, you don't need to know every refactoring listed above. Instead, you can follow the example code that illustrates how the listed refactorings are implemented. However, if you want to get the most out of this book, I do recommend that you have Refactoring close by your side. It's an invaluable refactoring resource, as well as a useful aid for understanding this book.
The patterns I write about come from the classic book Design Patterns DP, as well as from authors such as Kent Beck, Bobby Woolf, and myself. These are patterns that my colleagues and I have refactored to, towards, or away from on real-world projects. By learning the art of pattern-directed refactorings, you'll understand how to refactor to, towards, or away from patterns not mentioned in this book.
You don't need expert knowledge of these patterns to read this book, though some knowledge of patterns is useful. To help you understand the patterns I've written about, this book includes brief pattern summaries, UML sketches of patterns, and many example implementations of patterns. To get a more detailed understanding of the patterns, I recommend that you study this book in conjunction with the patterns literature I reference.
This book uses UML 2.0 diagrams. If you don't know UML very well, you're in good company. I know the basics. While writing this book, I kept the third edition of Fowler's UML Distilled Fowler, UD close by my side and referred to it often.
Unknown Binding
First published January 1, 2004
159 people are currently reading
4675 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 46 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.
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.
December 29, 2011
Very good explanations of each refactoring process that the author undertakes along with code snippets, thought process, steps involved, testing the changes, etc. As a developer you'd want to get into that habit of always refactoring your code to a cleaner / better version.
September 7, 2014
Loved the way refactorings were presented - steps to follow to keep the code compiling and passing tests as much as possible while refactoring - very detailed, felt like pair programming w/ author. Also good reasoning.
Displaying 1 - 30 of 46 reviews