Format of the Refactorings

Prev don't be afraid of buying books Next

The format of each refactoring in this book mostly follows the format used by Martin Fowler in Refactoring [F], with a few of my own embellishments. Each refactoring generally has most, if not all, of the following parts.

  • Name: The name is important for building up a vocabulary of refactorings. The refactorings in this book refer to numerous refactorings in Refactoring as well as refactorings in this book.

  • Summary: Each refactoring in this book describes a design transformation. I use textual and diagrammatic descriptions to explain each transformation. I call the diagrammatic portion of the summary a sketch because it uses UML to show the essence of a design transformation. The sketches use a variety of UML diagrams, including class, object, collaboration, and sequence diagrams. The sketches rarely show every method or field within a class, as that would distract the reader from the essence of the transformation. Most of the sketches also include gray boxes that contain the names of important participants in a refactoring. For example, the diagram on the next page shows the "after" sketch from Move Embellishment to Decorator (144).



    The participants listed in the gray boxes, "Decorator: ConcreteDecorator" and "Decorator: ConcreteComponent," both originate from the Participants section from the Decorator pattern in Design Patterns [DP]. In some cases, the participants listed in gray boxes originate from the names of classes or methods that I write about in the Mechanics section of a refactoring.

  • Motivation: This section describes why you'd want to use this refactoring. It also tends to include high-level descriptions that give a good overview of the patterns. If you need further details, it will be best to consult a book that describes the particular pattern in depth.

    At the end of the Motivation section, I include a box that lists the benefits and liabilities associated with the refactoring. A plus sign (+) signifies a benefit, while a minus sign (–) signifies a liability. Here's an example from the refactoring Replace State-Altering Conditionals with State (166).

    Benefits and Liabilities

    +

    Reduces or removes state-changing conditional logic.

    +

    Simplifies complex state-changing logic.

    +

    Provides a good bird's-eye view of state-changing logic.

    Complicates a design when state transition logic is already easy to follow.







  • Mechanics: This section lists the step-by-step instructions for implementing the refactoring. Some Mechanics sections include a preamble that describes what ought to be in place before you begin the refactoring. All of the Mechanics sections include numbered steps, so you can easily correlate these steps with the numbered steps in the Example sections.

    You'll find that the Mechanics sections reference many of the refactorings in Refactoring [F]. To fully understand the Mechanics sections in this book, I suggest that you have Refactoring close by your side.

    I also advise that you don't treat these sections like gospel. At best, they offer a safe way to get from one design to another. If your situation demands an alternate path, don't hesitate to try it. Also remember that you can often follow the steps in a Mechanics section part way, and if you achieve enough of a design improvement, stop there. Only implement all the steps of a Mechanics section if doing so truly improves your design.

  • Example: This section is where I go into great depth about how I used the refactoring in question to transform a design. Each step within an Example section is numbered and correlates with the numbered steps in the Mechanics section for that refactoring.

    I follow Martin Fowler's style of using boldface code (like this) to highlight changes made to code during the steps of each refactoring. Like Martin, I also use a strikeout font (like this) to show when I'm deleting code.

  • Variations: A few refactorings in this book include a section that explains a variation on the refactoring. This section is by no means exhaustive—there are far too many variations on refactorings to describe them all. However, I do document some important ones.

Amazon


Refactoring to Patterns (The Addison-Wesley Signature Series)
Refactoring to Patterns
ISBN: 0321213351
EAN: 2147483647
Year: 2003
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net