Well done book, and a valuable next-step in learning about design patterns. The original GOF presents them in isolated and rather sterile format and manner, this book adds a much richer context and analysis in actually using them in application refactorings.

An EXCELLENT book! Very highly recommended. I like the fact that Josh has used real world code in all the refactoring to patterns examples.

I read this book shortly after reading Martin Fowler's Refactoring book. I find this book to be a great extension to Fowlers basic priciples. It requires you to have some knowledge about basic refactoring terminology and techniques, and you should also have at least skimmed through the Gang of Four patterns book. Where this book has it's force is in helping you to identify when to do what types of refactoring and when NOT to do certain refactorings. It has a nice list of smells and their appropriate refactorings
I would recommend this as a reference book to all programmers that appreciate the value a well applied pattern has.

I've looked over some of the other reviews on here and disagree with much of the criticism. This book is very easy to navigate and use and a book that will help teach you patterns in a most practical way, by helping you find which pattern to apply to improve bad code when you need it. I've used this book frequently to find better solutions to bits of code that I just know could be improved and have expanded my knowledge of patterns in the process in a way that I never could by picking up a book on Design Patterns and studying them. If you enjoy learning in a hands on way, I think you will come to learn patterns and improve your code by having this book on hand at your desk to turn to. The patterns listed in this book are the ones that Software Engineers can use on a daily/frequent basis. These are patterns an Engineer should know well enough to just apply to code when they see the need has arisen. I think this book is very useful to Engineers who would like to learn software well enough to just be able to crank out good code when addressing daily problems.

This book is an important contribution to the design patterns library, particularly for practicing programmers as opposed to theoreticians. Most of the design books that we read deal with patterns in a vacuum, constructing toy examples which demonstrate the pattern at hand but have little in common with the kinds of software contexts that we are likely to encounter as serious programmers. Typically we are not designing systems from scratch; normally there is some combination of new and legacy code that must be made to cooperate in some coherent way, and we may perceive that some pattern would be desirable, but executing the transformation of the existing systems to express that pattern will typically involves significant risk of regression. That is a central focus of this book: how to break up this transformation into sequences of safe re-factorings.

Another important theme of the book is that the application of patterns typically entails various trade-offs. A well-known pattern may better communicate the relationships and responsibilities of the various software components we are working with, but on the other hand the pattern may introduce extra complexity if the problem being solved is amenable to some simple and minimal approach. Using the approaches of this book it is possible to introduce patterns if needed later in the development cycle, and in many cases it may turn out that the patterns are in fact not needed. In these situations, the lengthy application of patterns upfront would have been a premature optimization.

And this brings me to the last point that I want to make about this book: its content is strongly based on real world experience, and presented in a way which fits what we need as real world engineers. I thought it was interesting to see a negative review of this book where the complaint was that the author was talking about his own experiences too much. The relating of the theory presented to actual past problems solved is one of the most valuable aspects of the book, in my opinion.

I have read this book after reading Design Pattern and Refactoring. I found Chapter 1 - 3 are fantastic. But one drawback of the examples is the author used XML extensively in the book. Since XML is no longer glorious and still not so popular, using it as the example made the readers lost in translation. Unlike him, Martin used common domain knowledge in his books so people can capture the concepts easily.

I don't think Peter's one star is fair for the author, since Joshua gave a lot of insights in this book so it still worths reading. I commented his review. I have read this book again and my opinion didn't change.

I found one way to judge a book is to use Amazon used book price. This book is $19.97 as of today while Martin's Refactoring is $38.50(there is a paperback International Edition as $29.99 which doesn't count). It reflects the value of the book.

I had the book and found, as some of the other reviewers have commented, that it lacked complete code examples. The author has an online course (extra $s) that gives the level of detail/code that I need. I am working my way through the online material (60% through) and at this point I can say that the money on the book and the online material was worth it.
I suppose the real value of the book is that it convinced me that it would be worth my while spending the extra money to look at the online material. However, at this point it's hard for me to rate the book on it's own. The overall package, though, is definitely worth five stars.

What a disappointment! The book deals with a key element of software development but unfortunately lets the reader down in so many ways! While the topics covered should have been useful, I suspect that the most common word in the book was "I" - as the author regales the use with instances where his apparently superior and hothouse intellect saved the day. Instead, a concise but generalised explanation would have done and been illustrative.

Similarly, the book is filled with torturous language and passages absolutely berefit of meaning; for example pg 107 "Now it's time to reflect on how simple TagBuilder is and how easy it is for clients to use. Is there a simpler way to produce XML? This is not the kind of question you can answer right away. Experiments and hours, days, or weeks of reflection can sometimes yield a simpler idea. I'll discuss a simpler implementation in the Variations section below. For now, I move on to the last step. " on page 111 we finally got to the above mentioned Variations section in the interim 40+ references to "I" and "WE".

Finally, the author appears so in love with refactoring and artistic code that I really believed he exceeded good practice and drove towards refactoring to the infinitely useless. Several scattered recomendations to constrain class size to 10 lines of code and recommendations on how do so completed the picture for me. Too many flowers and not enough Vulcan warriors would be a good summary.

Last year, I led a large team in succesfully completing 40 Million Euro of software. (Yes, the sale value as sold to the customers) and commercially, i am not sure I would have a place in my team for such a polarised thinker.

I agree with the reviewers who complain about the lack of full source code (either in the book or on the Web for me to download), as a C# programmer I found it very difficult to follow the changes he was making from the small densely packed Java snippets.

Thats not to say I wouldn't recommend people to buy/read this book as its a decent book with lots of useful information and I really hope that any future editions improve on the quality.

There seems to be a common misconception that Refactoring and Patterns are disconnected things. I had high hopes that this would be the book that cleared this misconception and tied them together.

But I found the examples to be contrived, and often not deserving of the patterns that were applied. The step-by-step examples were hard to follow as they constantly gave tiny snippets of code that were missing proper context.

As important as I think this topic and message is, I can't imagine this book convincing anyone who wasn't already convinced. At best, this might make a passable supplement to someone learning patterns for the first time from another source.

On the bright side, some of the stories in the early chapters were entertaining, but not enough to recommend this derivative work.

The book discusses how you can refactor your existing code using design patterns. Unlike many other pattern books it doesn't limit itself to the famous GoF patterns, also includes other less known ones.
It has a clear structure, which is followed for all patterns: 1) shows the original design, 2) shows the target design, 3) gives background on the pattern discussed with pros and cons, 4) step-by-step takes you through the refactoring process.
I find it very informative and use it as reference frequently.
The only reason I'm not giving 5 stars is that the examples are sometimes complex ones, which are hard to follow in the way they are presented. Prefer to read more self-contained sort of books where you can understand the topic without additional supporting material (like code downloads). It would be better if the book showed the complete refactored code at the end of each pattern, to give the full picture.
I recommend it for experienced programmers, who are already familiar with patterns because the book's main focus is rather the refactoring process than the introduction to the basics of patterns.

Patterns Refactoring -- Perhaps the most important concepts in nowaday software development on complicated business platform. It's especially useful on the projects with critical design time phase in which the pattern design and refactor can be implemented on post-development phase. The Factory, Singleton, Adapter, Bridge, Decorator, Facade, Observer, Command, Template, Strategy, Mediator and State pattern are obviously purposed for elegant and well-maintainable technical design.

This book is one of my latest favorites although I picked from my work library..this book really a concepts guru. The author justifies why you need this book exploring what a typical developer do... right from the "Over Engineering", Patterns Panacea, Under Engineering...and finally justifing "Continous Refactoring". If you are developers, who realize patterns based approach then it is a must read. As a patterns fan, I chose to read this book after my favorite patterns collection GoF, Head first patterns, Core J2EE patterns, Core Security Patterns, Enterprise Integration Patterns ....and it truly made a difference so that I don't do over-engineering and under-engineering with my patterns.

If you are interested in understanding design patterns explained in detail, yet also inplain English, then this is the guide for you. Many aspects of how patterns are implemented and even combined are explored and therefore the advice provided by the book can be applied to various scenarios. Well worth the money and a bit of rollercoaster ride of read...

Design pattern concepts can be rather abstract at times, and the absence of code samples can make some of these concepts even harder to visualize. In this book, the author does an excellent job of applying design pattern concepts to code refactoring, thereby helping illustrate such an abstract subject. The contents of the book are thoughtfully structured such that the reader can focus on a specific pattern or specific refactoring problem,instead of reading through the chapters sequentially. I found the UML diagrams especially helpful, since they clearly delineated the design before and after, refactoring. However, the book falls short in terms of utilizing some of the coding samples, as the author tries to step though each code sample and loses the reader in the process. These exercises would have been a lot more fruitful and lucid had there been source code for the designs, before and after refactoring.

A number of times I thought I understand the refactoring after I read the summary at the beginning of each section, as well as the benefit and liabilities.

However, I got myself into trouble when I started reading the source codes. Code snippet worked in certain occasions, but failed in others.

The author could help readers like me if he could provide complete copies of source codes before after the refactoring on a CD or a web site.

This is a very good reference/utility book for any software designer, developer, maintainer... Unlike the traditional design pattern books, which talk about how to apply various design patterns under various situations, this book focus more on how to find badly designed and implemented code and apply simple yet effective patterns to make the existing code better. The author starts with listing some common problems in the existing code, such as conditonal complexity, long method, etc. He goes on by suggesting some possible solutions to the problems, such as using a strategy pattern to reduce conditional complexity, etc. He uses some very good examples and shows the detail steps involving in the refactoring process.

This book deserves "*****" if the complete source code before and after refactoring is available. Without the complete source code, it takes much more time and effort in trying to understand what is involved in the refactoring process.

This book will change the way you think about and working with exisiting code and Joshua Kerievsky does a great job of describing how to improve the design of existing code by performing various refactorings. But without FULL Source code some time it is difficult to understand..what he is trying to say!!!!

I found this book to be very readable. It combines refactoing and patterns. The refactoring shows how to improve existing code in order to improve maintenance and start on the road to patterns. I find the ideas can be used in practice and a group of us are using the book to see how we can improve the code base. The book makes extensive use of ideas from the Martin Fowler book, so it may have helped if I had read that book first. The examples tend to be small subsections of java code and you see how to change by applying a series of refactorings. Sometimes the examples seem to jump so a little larger examples would have helped. I liked that the examples are taken step wise so you can see that the code can change in an evolutionary manner.I would recommend this book for anyone doing software development.

The book is good in terms of how it is organised and the topics that it covers.

However, the choice of the type of examples used are poor. I recommend that the entire listing of the code before refactoring and after refactoring should be provided along with each chapter. Often I got lost while walking through the code snippets, as the steps that the author is walking through does not necessarily match the way I would walk through the code while refactoring using patterns. Sometimes it is hard to predict why the author did what he did, although it is just an intermediate step to to reach the ultimate goal. Some of the code snippets does not match the class diagrams and caused added confusion.

The lack of full source code makes it hard to see the big picture of what the author is trying to convey. It doesn't even have a CD nor a link to a page where you can try and download the snippets he has in the book. These drawbacks prompted me to rate this book to 3 stars, though it could have been better had he provided those resources that could reinforce the concepts, and of course for me to test them.

It would have been much better if it contained the FULL source code or at the very least the availability to download such. The book however has benefited our group of about 12 in identifying "smelly" code. After which and using Joshua's examples we were able to apply some low level refactorings and some of the more comprehensive refactorings which has made our code more clear. Good Book. Hopefully the source code becomes available...then I will revise my stars to 5.

The book is great, and I've learned a lot from it. I REALLY wanted to give it 5 stars, but the lack of full source code for the examples, detailing before and after application of the refactoring techniques, forced me to give it a 3. Ended up spending way too much time trying to piece together the snippets of code in order to fully understand what was going on.

This is probably the best technical book I read that was published in 2004. If you are struggling to see how you can apply patterns in your day-to-day work, this book will help.

Most development work is done with existing code bases. It is less likely that you will have a chance to design something from scratch using design patterns that you are aware of. So this book helps you move toward a code base that is better designed in refactorings that lead to common design patterns.

The author suggests that many systems are now "over-engineered" due to the popularity of design patterns. I have not had the opportunity to work on such a system, but the book was still very relevant.

The code examples are actually very realistic and detailed, which I appreciated. Some readers may find them too complex and distracting from the refactoring steps, but I thought they strengthened the book.

I read the book in the order suggested by the author to those who want to study the patterns. It worked very well and the code examples carried thoughtfully from one refactoring to the next.

Examples are in Java but if you are using any OO language you will likely be able to follow them.

Many technical books are filled with typos and grammatical errors. This book was obviously well edited and not rushed out the door to publish.

Kerievsky has written a very useful book and I recommend that all programmers read it. The unification of the two worlds of "patterns" and "refactoring" makes perfect sense, and I find this book an excellent companion to the GOF Design Patterns book. While the original Design Patterns is a classic, it's presentation of finished patterns made it difficult for programmers to relate these abstract concepts to their own everyday experience. Kerievsky addresses precisely that problem, and my only criticism would be that the source code associated with each refactoring is not available online. Hoewever, even in the absence of digital copies of the source code the book is extremely useful, especially for the legions of programmers who must maintain legacy code from earlier systems. An issue that every programmer faces on a daily basis to a greater or lesser degree.

Refactoring To Patterns brings together the Patterns movement, and the practice of Refactoring commonplace in the Agile community. Whereas the original Gang of Four book told us what patterns were, what sort of problems they solved, and how the code might be structured, Refactoring To Patterns illustrates how, why and when to introduce patterns into an existing codebase.

The opening chapters cover the background, introducing both refactoring and design patterns, and the context in which the book was written. This gives the reader a clear overview of what is involved in Refactoring to Patterns, and paves the way for the refactoring catalogue which makes up the bulk of the book.

The catalogue is divided into chapters based on the type of change required --- is this a refactoring to simplify code, generalize code, or increase encapsulation and protection? Each chapter has an introduction which gives an overview of the refactorings contained within that chapter, followed by the refactorings themselves. These introductions clearly illustrate the principles and choices which would lead one to follow the refactorings that follow.

Each refactoring starts with a brief one sentence summary, and before and after structure diagrams with reference to the structure diagrams for the relevant pattern in the Design Patterns book. The sections that follow then cover the Motivation for using this refactoring, step-by-step Mechanics, and a worked Example, relating back to the steps given for the Mechanics. Finally, some of the refactorings finish with Variations on the same theme. The examples are all pulled from a small sample of projects, which are introduced at the beginning of the catalogue section, and help illuminate the instructions given in the Mechanics section. The mechanics themselves are generally clear, and broken down into small steps --- sometimes smaller steps than I might take in practice, but I think this is probably wise, as large steps can easily confuse. Finally, the Motivation sections do a good job of explaining why one would choose to do a particular refactoring, and any pitfalls to doing so --- the "Benefits and Liabilities" tables provide a useful summary.

This book is well written, easy to read, and genuinely useful. It has helped me put some of the refactorings I do into a larger context, and given me insight into how I can integrate patterns with existing code, rather than designing them in up front. As John Brant and Don Roberts highlight in their Afterword, this is a book to study, the real benefit comes not from knowing the mechanics, but by understanding the motivation, and the process, so that one may apply the same thinking to other scenarios not covered by this book. If you are serious about software development, buy this book, inwardly digest it, and keep it by your side.

Highly Recommended.

To sum it up nicely, this is a good book, very good. I could have lived without all the XML/DOM, though, but still the kind of quality you can usually expect from Addison Wesley publishing.

This book is the only one of its kind that tries to use a patterns approach to refactoring. It is a good add-on to Martin Fowler's book. It's a very valuable contribution to the refactoring community. Kerievsky has a no-nonsense, down-to-earth approach to the subject of Patterns. However unlike Fowler who makes an effort to keep the code examples in his book as simple as possible, Kerievsky has made his examples over-complicated with all kinds of detailed finance domain references and the XML DOM. The example he uses to show how the Builder pattern simplifies creation of Composites is like a really heavy chapter on XML processing/generation.
The "Replace Conditional Logic with Strategy" is like a chapter on Investments / Loans. It really distracts the reader's attention from the pattern or refactoring.
This is a shame because it is impossible to write a good book on refactoring without nice examples. It is also a bit surprising that none of the other Amazon reviews mention this issue.

Code Complete, Design Patterns, Refactoring, Extreme Programming Explained, Design Patterns, Refactoring to Patterns, Code Complete... you get the idea.

This is a recent book in Martin Fowler's series of computing texts. The series begins with his classic Refactoring text. Now Kerievsky takes us into a sequel. Because you can imagine this as a suitable extension of the previous book. Where now the author has us look for patterns during the refactoring process. The style of the book closely follows Fowler's book. And, like that book, the code examples are in Java.

But what if you program in C++ or C#? If you are experienced enough, you should be able to apply many of these ideas in your language. The examples are meant to give flesh to general patterns. And the patterns should be able to be implemented in any object oriented language.

Actually, if you have already been looking for patterns, or designing to them, then much of this book may be no surprise. Because one virtue of the book is that it binds together a set of commonly encountered refactorings. But even in this case, a few hours reading may be profitable for you, if it just exposes you to a few hitherto unfamiliar patterns.

Patterns have always been the domain of the 'architect type'. This book turns that around. It provides practical insight at the code level in how to improve code structure using patterns. What's more it provides these insights on existing code bases. Most of us don't start projects, we extend existing projects. This book tells us how to refactor this existing code in practical ways that will end up making the code more maintainable and reliable.

I can't hold the GoF responsible for the architectural bias in patterns. The original Design Patterns book was very practical in nature. Design patterns just had better penetration in the architecture world. With this book Kerievsky brings patterns back to the front line implementers.

I recommend this book for any software engineer. Thank you Joshua! Great job.

A high quality reference for those that want to gain some direction to their refactoring. That's what Joshua Kerievsky has managed to create with this book. This book assumes that you already know about refactoring and even states clearly that this book is best read with Martin Fowler's "Refactorings" as a reference. With that prerequisite in mind, this text does an excellent job of introducing the process of using refactorings to fix code problems by introducing patterns into your design.

Some of the strongest points include: editing, organization, and clarity. My hat goes off to the editor(s) of this book as I found very few errors even though this book contains a lot of "real world" code. Organizationally, this book does an excellent job of making itself useful as a "read-through" book for those that want to immerse themselves in the topic and as a reference book that can sit on your shelf until you need it.

One word of caution about this book is that it originally started as a paper and grew from there. Especially throughout the first few chapters of the book, this is very evident. Constant references to works done by other authors and numerous footnotes can, at times, become a bit distracting from the overall message.

Overall, this is an excellent book and, if you're into extreme programming and refactoring, it's one that you're going to want to have on your shelf.

Based on its title alone I had high expectations for this book. It didn't disappoint. The book takes two of the most important advances of the past decade (patterns and refactoring) and puts them together into a whole that is definitely more than the sum of its parts.

I've read many good patterns books and have been applying patterns to how I think and talk about software since the original "Design Patterns" book in 1995. However, something was always missing. Through my consulting work, whenever I introduced patterns to a new team they would take quickly to the idea and patterns would become part of how they thought-but only when designing, not when coding. Since we spent more time coding than designing, patterns played less of a role than they could have.

This book does an excellent job of bringing patterns into coding, rather than relegating them just to design discussions. As the author points out, "patterns are best viewed in the light of refactoring and that they are destinations best reached by applying sequences of low-level refactorings."

This book has earned a permanent place on my bookshelf. That is, when it's not open beside me as I program. Very highly recommended!

i just finnished reading this book and i was very suprised about the simplicity and especially everything i could read between the lines. it's very funny if you recognize yourself inside his stories about real world anti patterns. (yes, i'm pattern happy ;D) i liked it more than fowler's book, which was to basic, as i read many research papers before, anyway both are nice to have. i look in this book before taking design decisions,as a brainstorming partner if i develop alone. excellent work, buy it right now!

If you're thinking about this book, and you probably wouldn't be reading this if you weren't, you may just be puzzled by the title, or you may be wondering just what it's all about. No, it has nothing to do with cloth or wall paper. It's about software programming. Perhaps someone told you about this book and you're wondering what it is all about.

Refactoring, simply put is re-writing code to make it simpler, easier to understand without changing what the code does.

Patterns are simply common solutions to recurring problems faced by programmers.

This book is not intended to be your first programming book. But if you are working as a professional programmer, this book can help you write better, tighter, faster, easier to modify code. The title is the most imposing, even frightening part of the book. Inside it is clearly written and provides a lot of hints, tips and suggestions that are worth quite a lot.