Refactoring Workbook (Addison-Wesley Object Technology Series) [Paperback]

* Obscure or overly descriptive comments.
* Overly long methods.
* Overly large classes.
* Overly long parameter lists to methods.

and all examples are coded in Java. Programming veterans will recognize most of these problems as old and venerated programming difficulties. With the exception of large classes, they have been part of the list of bad programming habits for decades. However, the solutions require a bit of thought, it is conceptually simple to make comments, variable names and method names more descriptive, but of course there are reasonable bounds that reasonable people can disagree on. There are only rules of thumb available to guide us, and Wake sets down his thoughts on this matter.
The real difficult problems in this list, and where this book is the biggest help in this section, is in demonstrating how to make methods and classes shorter. To factor out just the right amount of code and still maintain the same level of understandability can be a difficult judgement call. Programmers learn best by seeing worked examples, so the sequence of presentation is:

* Symptoms.
* Causes.
* What to do?
* Payoff.
* Discussion.
* Contraindications.

Coding veterans will most likely find the "contraindications" section of the exercises the most helpful. It describes reasons why performing the refactoring may not be the best decision.
The second set of refactoring exercises are:

* Unnecessary complexity.
* Duplication.
* Conditional logic.

This set of refactorings will also be familiar to coding veterans. Removing dead code, eliminating duplicate code, deleting magic numbers and using more efficient Boolean operations have been on the list of good programming habits for decades. Therefore, the refactorings in this section are fairly routine, as they do not require an object-oriented example to demonstrate them.
The most valuable section of the book is the second one, where the coverage is smells between classes, which are as follows:

* Data.
* Inheritance.
* Responsibility.
* Accommodating change.
* Library classes.

Most modern programmers will be familiar with the first section and will have already done many of them as part of their general coding practices. However, the "smells" in the second list are those that always seem to creep undetected into large programs. Therefore, they are harder to identify and often even harder to remove. I found the segment on problems in library classes to be the most valuable one of the entire book. I often use library classes in Java and there have been times when I have looked at a library class and been puzzled by how it is constructed.
The book closes with four small programs that are to be refactored as exercises. Large and complex enough to be worthwhile exercises, they are an excellent conclusion to a helpful book. Many problems are included and solutions to almost all are found in an appendix.
While this book is a good way to practice refactoring, it is not a good way to learn it. The classic book by Martin Fowler is still the best introduction to refactoring.

The book includes over 100 exercises, many of which are answered in an appendix. I worked through the book alone but this is the type of book I'd love to work through with a group.