Refactoring: Improving the Design of Existing Code by Martin Fowler, The Addison Wesley Object Technology Series
images.amazon.com
ISBN:0201485672 Hit the shelves in mid-June of 1999. Sometimes known on Wiki as the Refactoring Book.
Official site:
Catalog of summaries:
Perhaps this book can serve as the starting point and dictionary for a Refactoring Language, much as Pattern Names, used together, can form a Pattern Language.
I picked up a copy at Java One. It's a wonderful book. It is organized roughly along the lines of the Gang Of Four book - some introductory chapters about what refactoring is, where it came from, and why you should care, followed by a catalog of refactorings. However, I found it to be a much more pleasant book to read than Design Patterns (as useful and important as that book is, I don't think it's an easy read).
Kent Beck wrote or contributed to three chapters (on Code Smells, Big Refactorings, and a summary explaining how refactoring fits into the bigger picture of software development
William Opdyke supplied a chapter on his experiences with refactoring in real-world projects.
Don Roberts and John Brant wrote a chapter on refactoring tools (informed by their work on the Refactoring Browser).
The book is well-written, thorough, and will spend the foreseeable future on My Lowest Bookshelf.
Like Fowler's book Uml Distilled, Refactoring is subversive. Along the way, readers learn about many, if not most, of the XP techniques and principles: pair programming, continuous unit testing (and writing unit tests first), You Arent Gonna Need It, Once And Only Once, and others. -- Glenn Vanderburg
If you've read Smalltalk Best Practice Patterns, you'll find this book is quite similar in a lot of ways. As well as showing you better ways to use the language, this book shows you how to take poor code and improve it by applying those patterns. It uses Java Language rather than Smalltalk Language and is much easier to apply directly for those of us using Cee Plus Plus. I couldn't recommend this book more! -- John Burton
Kudos, Martin! This book is fabulous! Within an hour, I had decided that I will order several copies to spread around my company. And I was thrilled when I showed it to a colleague first thing this morning only to learned that he ordered it this weekend after discovering it (and reading chapter 1) at a local bookstore. -- Kiel Hodges
I'd like to thank Martin for putting together some of the theory of Refactoring with some actual practice here. Writing code is not simply written, but evolved, and this book gives some very specific methods and pathways for common programming techniques.
The odd thing is, like Design Patterns, once you have seen the pattern (or idiom, or whatever you want to call it) you think to yourself Oh yeah, I do that (aka I Have This Pattern). But having a roadmap in front of you is a thought aid and useful reference point when you're in the thick of code without a flashlight.
I must also thank this book for introducing me to the Java Unit (actually JUnit, but that's not wiki friendly) testing framework. I would have liked to have seen more focus on the pre-emptive unit testing methodology as it seemed interesting, but I am concerned how it would scale up to large scale software projects, specifically client/server or distributed systems.
-- Will Sargent
Refactoring Improving The Design Of Existing Code seems to suggest that Local Variables Are Bad.
Or at least that they can be replaced with something better like a query. -- pg
One thing that I found confusing was the UML class diagram of JUnit on page 92. It shows that TestSuite and TestCase both implement <> Test. That much was reasonable, and consistent with Martin Fowlers Junit Paper. However, it also shows that TestSuite extends zero or more Test. -- Patrick Parker
That looks like an erratum. The relationship should be aggregation, rather than inheritance. That is, a TestSuite contains zero or more Tests.
JUnit uses the Composite Pattern. TestSuite both implements Test and contains zero or more instances of Test.
I just finished reading Chapter 6 and I have a question regarding Replace Method With Method Object. I have used this pattern before, creating an Inner Class to replace a classes method. The book makes no mention of using Inner Classes, and I was wondering if there are any reasons why you might not make the new Method Object an Inner Class?
Sure, why not? It's a simple extension of Replace Method With Method Object.
Personally I consider Replace Method With Inner Class to be the obvious implementation of the pattern. The question I was asking is: "Are there any times when using an inner class is inappropriate for this Pattern?"
Having finished reading Chapter 8 I thought I should ask why there was no treatment of the threading issues inherent in Duplicate Observed Data. The issue is that any modification of the Domain Object will be propagated to the GUI widgets automatically via the Observer update() method. As this occurs within the setter method of the Domain Object, it will run within the updating Thread not the GUI Thread. As neither AWT nor Swing are Thread Safe, this can lead to Data Race's and resulting bugs.
The solution is for the Domain Object to register an update with either javax.swing.Invoke And Wait() or javax.swing.Invoke Later(). Note that if you use Invoke And Wait() you must be careful you avoid Dead Lock, Invoke Later does not have this problem however it will leave your GUI Object and your Domain Object out of sync until the update runs.
Both functions use Runnable as a Functor Object, in most cases I use Anonymous Inner Classes for this.
-- Andrae Muys
Excellent book - wish I'd come across it sooner. Quite practical/hands on, though with decent explanations. I found the GoF book unreadable, so I bought a clone, which still makes some of the patterns clear as mud. This book however couldn't be clearer, and what's more it's easy to read - written with a light touch and interspersed with humour. I was pleased to see that I was already using most of the refactorings - but having a good reason why is very reassuring. Still not taken 'Change Unidirectional Association to Bidirectional' on board though - I'm sure I've needed to achieve the same end before, but I can't figure out how else I would have done it. 10/10 for Martin Fowler & co. -- Danny Ayers
Comments on the book by a self-described Relational Weenie moved to Refactoring Is Not Relational. (Any Wiki Master should feel free to provide a better name for the page. -- Steven Newton)
Dot Net Refactoring Tutorial:
You know, I'm still not happy with the use of the term design in relation to refactoring. Design happens before coding. Code is supposed to reflect design. Refactoring can improve implementation, but it really can't affect design. If it does then there was something wrong with the design in the first place, now wasn't there?
I beg to disagree. See Emergent Design.
See also Refactoring To Patterns
See original on c2.com 