There are many patterns that are not specifically concerned with re-engineering, but are still relevant to the re-engineering process. In this chapter we have listed only those patterns that are specifically referred to at some point in this book. We have grouped them into the following three categories:

• Testing patterns. These patterns help you to focus your testing efforts. Our principle source is a pattern language by DeLano and Rising [DR98], though of course a vast literature is available on the subject. Binder, for example, devotes an entire book to the subject [Bin99].

• Refactoring patterns. These patterns focus on individual refactoring steps that you might applying during a re-engineering project, or that you might just as well apply during any forward engineering project. Our principle sources are Fowler et al. [FBB⁺99], and the Roberts’ PhD thesis [Rob99].

• Design patterns. Very frequently the result of a re-engineering operation is to put a particular design pattern into place. Here we remind the reader of some of the most common design patterns that pop up in a re-engineering context. Our main source is, of course, the Design Patterns book [GHJV95].

A.1 Testing Patterns

A.1.1 Retest Persistent Problems

Problem: What areas of the system should receive concentrated testing, irrespective of the features being implemented?

Solution: Keep a list of persistent problem areas and test cases to verify them, not just for resolving the current problems but also for use in subsequent testing. Test these areas thoroughly, even if there are no new features going into them. Retest regularly using, even one last time before the release goes out of the door.

Source: Patterns for system testing [DR98].

Referenced from: Regression Test After Every Change [p. 182].

A.1.2 Test Fuzzy Features

Problem: How can possible problem areas of the system be pinpointed so that the most problems can be found in the least amount of time?

Solution: Study the documentation available on the system. Look for areas that seems ambiguous or ill-defined. Write test plans that cover these areas more thoroughly and concentrate testing in these areas. If designers can tell you all about a feature, it probably works. It’s what they can’t tell you that needs attention during testing.

Source: Patterns for system testing [DR98].

Referenced from: Grow Your Test Base Incrementally [p. 144].

A.1.3 Test Old Bugs

Problem: What areas of the system should be targeted for testing so that the most problems can be found in the least amount of time?

Solution: Examine problem reports from previous releases to help select test cases. Since it would be inefficient to test for all old problems, look at problems reported after the last valid snapshot of the system. Categorize problem reports to see if a trend is determined that could be used for additional testing.

Source: Patterns for system testing [DR98].

Referenced from: Grow Your Test Base Incrementally [p. 144].

A.2 Refactorings

A.2.1 Encapsulate Field

Also Known As: Abstract Instance Variable [Rob99].

Intent There is a public field. Make it private and provide accessors.

Source: Refactoring: Improving the Design of Existing Code [FBB⁺99].

Referenced from: Eliminate Navigation Code [p. 230].

A.2.2 Extract Method

Intent You have a code fragment that can be grouped together. Turn the fragment into a method whose name explains the purpose of the method.

Source: Refactoring: Improving the Design of Existing Code [FBB⁺99].

Referenced from: Refactor to Understand [p. 115], Visualize Code as Dotplots [p. 210], Move Behavior Close to Data [p. 221]

A.2.3 Move Method

Intent A method is, or will be, using or used by more features of another class than the class on which it is defined. Create a new method with a similar body in the class it uses most. Either turn the old method into a simple delegation, or remove it altogether.

Source: Refactoring: Improving the Design of Existing Code [FBB⁺99].

Referenced from: Refactor to Understand [p. 115], Move Behavior Close to Data [p. 221]

A.2.4 Rename Attribute

Intent Rename an instance variable and update all references to it.

Source: Practical Analysis for Refactoring [Rob99].

Referenced from: Refactor to Understand [p. 115].

A.2.5 Rename Method

Intent The name of a method does not reveal its purpose. Change the name of the method.

Source: Refactoring: Improving the Design of Existing Code [FBB⁺99].

Referenced from: Refactor to Understand [p. 115]

A.2.6 Replace Conditional with Polymorphism

Intent You have a conditional that chooses different behavior depending on the type of an object. Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract.

Source: Refactoring: Improving the Design of Existing Code [FBB⁺99].

Referenced from: Transform Client Type Checks [p. 257]

A.3 Design Patterns

A.3.1 Abstract Factory

Intent _Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Source: Design Patterns [GHJV95].

Referenced from: Look for the Contracts [p. 123], Transform Client Type Checks [p. 257].

A.3.2 Adapter

Intent Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

Source: Design Patterns [GHJV95].

Referenced from: Present the Right Interface [p. 187], Move Behavior Close to Data [p. 221].

A.3.3 Facade

Intent Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Source: Design Patterns [GHJV95].

Referenced from: Eliminate Navigation Code [p. 230], Split Up God Class [p. 239].

A.3.4 Factory Method

Intent Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Source: Design Patterns [GHJV95].

Referenced from: Look for the Contracts [p. 123]

A.3.5 Flyweight

Intent Use sharing to support large numbers of fine-grained objects efficiently.

Source: Design Patterns [GHJV95].

Referenced from: Speculate about Design [p. 87]

A.3.6 Null Object

Intent A Null Object provides a surrogate for another object that shares the same interface but does nothing. Thus, the Null Object encapsulates the implementation decisions of how to do nothing and hides those details from its collaborators

Source: Null Object [Woo98].

Referenced from: Introduce Null Object [p. 274].

A.3.7 Quantity

Problem: Representing a value such as 6 feet or $5.

Solution: Use a quantity type that includes both the amount and the unit. Currencies are a kind of unit.

Source: Analysis Patterns: Reusable Objects Models [Fow97].

Referenced from: Analyze the Persistent Data [p. 77].

A.3.8 Singleton

Intent Ensure a class only has one instance, and provide a global point of access to it.

Source: Design Patterns [GHJV95].

Referenced from: Read all the Code in One Hour [p. 45].

A.3.9 State

Intent Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

Source: Design Patterns [GHJV95].

Referenced from: Factor out State [p. 266].

A.3.10 State Patterns

Intent The State Patterns pattern language refines and clarifies the State Pattern.

Source: State Patterns [DA97].

Referenced from: Factor out State [p. 266].

A.3.11 Strategy

Intent _Define a family of algorithms, encapsulate each one in a separate class, and define each class with the same interface so they can be interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Source: Design Patterns [GHJV95].

Referenced from: Factor out Strategy [p. 270].

A.3.12 Template Method

Intent Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

Source: Design Patterns [GHJV95].

Referenced from: Look for the Contracts [p. 123].

A.3.13 Visitor

Intent Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Source: Design Patterns [GHJV95].

Referenced from: Move Behavior Close to Data [p. 221].

---

---