I rate the book with two stars because the introductory part of the book brings you some good ideas and thoughts. From that point, the reference material is too simple.

What impressed me most about this book was its attitude. Granted that the book expertly leads us through refactoring of smelly code; and granted that the catalog of refactorings are full of interesting insights. But still and all, it was the attitude that the value of a module was not maximized simply by making it work that really struck home.You can vastly improve a module without changing its function whatever. Morevoer, such function preserving, structure improving, changes are a normal and essential part of every engineer's role.

This is a must if you are new to OO coding principles.I found it very difficult to convert from structured coding to OO coding even after reading the "Head First Design Patterns" book, which is my second favorite book on learning practical OO coding.This book will help you look at your existing code and convert it to more object oriented code. Now, I just start my design and coding using my old coding practices, except that when I see an old coding style I used to perform, but I now know is referenced in the book, I stop myself and apply the recommended patterns from the book. So little by little I have grown more object oriented in my coding but by small easily understood steps.

What is better? Replacing delegations with inheritance or replacing inheritance with delegation?The answer is the ultimate answer to most software engineering decisions: DEPENDS, there is always a trade-off that has to be analyzed according to the context! This book addresses those trade-offs very well.Moreover, I like the examples in the book, good to use in class when teaching. They generate interesting discussions.

The content itself is excellent -- the discussion of refactoring is absolutely great. I would give the content itself a good four or perhaps five stars.Sadly, the Kindle version is broken. The book uses example code before a refactor and after a refactor to illustrate its points, and I believe in the print version the two versions are displayed side by side. Unfortunately, in the Kindle version this side-by-side layout is destroyed, making the comparisons useless.I have read over twenty Kindle editions of books on the iPhone, iPad and my desktop, and I've never felt disappointed. Sadly, the Kindle version of "Refactoring" feels like a waste of money.

Refactoring, says Fowler in his preface, is improving the structure of the code without changing the behavior at all. His book certainly offers an organized way to do that, with examples and then an entire second half of the book which is a reference of refactoring patterns. I can recommend reading the first half of the book (methods) and then keeping it around as a reference when needed.But as a constant daily method, I think it claims too much. "Improving the design of the code after it has been written," is still difficult, even if you have a book of refactoring patterns. And Fowler rightly makes having a strong unit testing suite a requirement.So I can say: read the book so that if you find yourself doing refactoring, you won't have to reinvent the wheel. But don't get your hopes up that refactoring is a substitute for good design and clear coding, as measured and improved through review by trusted co-workers.