What Are The Goals Of This Book?

This Book Was Written To Help You

  • Understand how to combine refactoring and patterns
  • Improve the design of existing code with pattern-directed refactorings
  • Identify areas of code in need of pattern-directed refactoring
  • Learn why using patterns to improve existing code is better than using patterns early in a new design

To Achieve These Goals, This Book Features

  • A catalog of 27 refactorings
  • Examples based on real-world code, not the toy stuff
  • Pattern descriptions, including real-world pattern examples
  • A collection of smells (i.e. problems) that indicate the need for pattern-directed refactorings
  • Examples of different ways to implement the same pattern
  • Advice for when to refactor to, towards or away from patterns
  • A suggested study sequence for the refactorings

Who Is This Book For?

Objected Oriented Programers Who

  • Are engaged in or interested in improving the design of existing code.
  • Use patterns and/or practice refactoring, but have never implemented patterns by refactoring
  • Know little about refactoring and patterns and would like to learn more

The Types Of Projects For Which This Book Is Useful Are

  • Greenfield development, in which a new system or feature is being written from scratch
  • Legacy development, in which you are mostly maintaining a legacy system.

Whether you are doing greenfield or legacy development, the refactorings and design ideas in this book will help you with your work.

What Background Do You Need?

Assumptions and References

This book assumes you are familiar with design concepts like tight- or loose-coupling and object-oriented concepts like inheritance, polymorphism, encapsulation, composition, interfaces, abstract and concrete classes, abstract and static methods and so forth.

I use Java examples in this book. I find that Java tends to be easy for most object-oriented programmers to read. I've gone out of my way to not use fancy Java features, so whether you code in C++, C#, VB.NET, Python, Ruby, Smalltalk or some other object-oriented language, you ought be able to understand the Java code in this book.

This book is closely tied to Martin Fowler's classic book, Refactoring [F].

Contains References to These Low-Level Refactorings

  • Extract Method [F]
  • Extract Interface [F]
  • Extract Superclass [F]
  • Pull Up Method [F]
  • Move Method [F]
  • Rename Method [F]

Contains References to These Sophisticated Refactorings

  • Replace Inheritance with Delegation [F]
  • Replace Conditional with Polymorphism [F]
  • Replace Type Code with Subclasses [F]

Understanding Pattern-Directed Refactorings

To understand the pattern-directed refactorings in this book, you don't need to know every refactoring listed above. Instead, you can follow the example code that illustrates how the above refactorings are implemented. However, if you want to get the most out of this book, I do recommend that you have Refactoring [F] close by your side. It's an invaluable refactoring resource, as well as a useful aid for understanding this book.

The patterns I write about come from the classic book, Design Patterns [DP], as well as from authors such as Kent Beck, Bobby Woolf and myself. These are patterns that my colleagues and I have refactored to, towards or away from on real-world projects. By learning the art of pattern-directed refactorings, you'll understand how to refactor or towards patterns not mentioned in this book.

You don't need expert knowledge of these patterns to read this book, though some knowledge of patterns is useful. To help you understand the patterns I've written about, this book includes brief pattern summaries, UML sketches of patterns and many example implementations of patterns. To get a more detailed understanding of the patterns, I'd recommend that you study this book in conjunction with the patterns literature I reference.

This book uses UML 2.0 diagrams. If you don't know UML very well, you're in good company. I know the basics. While writing this book, I kept the third edition of Fowler's UML Distilled close by my side and referred to it often.