The Refactoring To Patterns book seemed like a good one to follow up both the canonical Refactoring and Design Patterns books.
The book aims to bridge the gap between the two topics, listing design patterns and 27 refactorings to move to, towards, or away from them (refactoring away from a design pattern is only used when the change also refactors the code towards another pattern). The refactorings tend to be rather high-level (in that they include steps comprised of lower-level refactorings such as ‘Extract Method’) so it is a good idea to have a firm grasp of those lower level ones first (or have a tool that does them for you).
I like that the author shows that there is value in changing code to move towards a specific pattern, without necessarily moving all the way there, which is helpful in both legacy projects where you’re attempting to limit the change you make, and for smaller projects where the full pattern would be needlessly complex.
For each refactoring, there is a description of the change about to be made, a list of points for and against making the refactoring, a before and after code diagram (in UML), and both a mechanics section (which explains the steps of the refactoring in the general case) and an example section (which provides a ‘real-world’ example of this refactoring in action). I am familiar with a lot of the refactorings already so I tended to skip the mechanics section and just read through the example (although some of the refactorings have multiple mechanics sections, if there are multiple ways of changing the code to get the result required, so in those cases I tended to read the mechanics section also).
The ‘real-world’ examples are a nice touch, they are based on a small number of projects that are either open-source or sanitised, and each code sample is used in many refactorings, so you can see the larger picture of how the code was improved by employing more than one pattern (and there is even a suggested reading order which takes you through how the refactorings were applied to the code in sequence).
I also liked some of the new refactorings that were introduced, in particular Compose Method, which I find I use a lot in my coding and really helps me to explain the code without having to resort to comments (with the bonus that you end up with a large number of private methods that are so small you don’t have to think about them).
The code samples are written in Java, which is even easier to grok than the C++ and Smalltalk examples used in Martin Fowler’s book, though with the supporting diagrams, mechanics, and example sections, all programmers should be able to follow the transformations.
All in all I think this is a valuable book to read once you are comfortable with both refctoring and design patterns, going through it gave me a few ideas on how to solve issues I was having with the various code-bases I’m responsible for, and has equipped me with the knowledge of how to solve design issues I’m likely to come across in the future.