Refactoring to Patterns — Joshua Kerievsky

What the book is about

Written by Joshua Kerievsky, Refactoring to Patterns sits at the intersection of two foundational books: Martin Fowler’s Refactoring and the Gang of Four’s Design Patterns. Kerievsky’s central argument is that design patterns should not be applied upfront — they should be grown into through refactoring, when the code itself makes the need for them visible.

This is a significant reframing. The traditional view of design patterns treats them as architectural decisions made at the start of a project. Kerievsky treats them as destinations you arrive at by listening to the code. A system that is hard to extend in a particular direction is telling you something. Refactoring to the right pattern is the response.

The book assumes familiarity with both Fowler’s refactoring catalogue and the GoF patterns. It is not an introduction to either — it is the synthesis of both into a unified practice.

The core idea: incremental design

Kerievsky draws on the Extreme Programming principle of incremental design: do not design for a future that has not arrived yet. Start with the simplest solution that works. Refactor when the design no longer serves the code. Let the patterns emerge from that process rather than imposing them from the outside.

This approach directly addresses one of the most common problems in object-oriented development: over-engineering. Applying a pattern before the problem it solves is real adds complexity without benefit. The pattern adds indirection, the indirection requires understanding, and the benefit never materialises because the anticipated complexity never arrived.

The inverse problem — under-engineering — is what the refactorings in this book address. When the code has grown to the point where a pattern would genuinely simplify it, Kerievsky shows the sequence of small, safe steps that gets you there.

Selected refactorings

Replace Constructors with Creation Methods — when a class has multiple constructors that are hard to distinguish by signature alone, replace them with named static factory methods that communicate intent. The name of the creation method is the documentation.

Move Accumulation to Collecting Parameter — when a method builds up a result by passing a mutable object through multiple calls, introduce a collecting parameter that makes the accumulation explicit and the result easier to follow.

Replace Conditional Logic with Strategy — when a method contains conditional logic that switches on type or state, replace the conditionals with a Strategy object per case. Each strategy encapsulates one variant of the behavior. Adding a new variant means adding a new class, not editing existing ones. This refactoring appears throughout the book as one of the most impactful — and is directly relevant to anyone refactoring ABAP code with complex IF/ELSEIF or CASE chains.

Compose Method — break a long method into a set of equally-abstracted calls that read like a summary of what the method does. A well-composed method tells you what happens at a high level; the extracted methods tell you how.

Replace Implicit Tree with Composite — when code builds a hierarchical structure through implicit nesting or manual recursion, replace it with the Composite pattern, which makes the tree structure explicit and the traversal uniform.

Move Embellishment to Decorator — when conditional logic adds optional behavior to an object, extract the embellishment into a Decorator that wraps the original. This keeps the core class clean and makes the optional behavior composable.

The relationship to Fowler and GoF

Kerievsky is explicit about the lineage of his work. He uses Fowler’s refactoring mechanics as the building blocks — the individual steps of Extract Method, Move Method, Replace Conditional with Polymorphism — and uses the GoF patterns as the targets. The result is a catalogue of compound refactorings: sequences of smaller steps that, taken together, move the code from one design to a better one.

Reading this book after Refactoring and Agile Software Development makes all three more useful. Fowler gives you the tools, Martin gives you the principles, and Kerievsky shows you how the tools produce the patterns the principles demand.

Personal statement

Refactoring to Patterns is a demanding read — it rewards developers who already have experience with both refactoring and design patterns. As an introduction to either, it would be overwhelming. As a synthesis of both, it is excellent.

The central idea — that patterns are destinations you refactor toward, not starting points you design from — is one of the most practically useful reframings in the clean code space. It dissolves the tension between “just make it work” and “design it properly” by turning design into a continuous, incremental activity rather than an upfront commitment.

Among the books in this series, it sits closest to Refactoring by Fowler and Agile Software Development by Martin. Read those first, then come back to this one.