4.  Terminate the tool with the footer text (lines 58–59) Those parts of the algorithm that are domain specific are underlined and will be refactored as methods using the Extract Method refactoring. For example, I'll create a method getTitle():

protected String getTitle() {
return "Sales Statistics for Period ";
}

The corresponding part of the export method is:

PlanningTool planningTool =
ExporterHelper.initializeTool(
getTitle() + startYear + "-" + endYear,
getNumberOfColumns());

When doing this type of refactoring, I try to use method names that indicate the role performed by these lines in the original methods. Using this approach, it's easy to extract the methods getTitle(), getNumberOfColumns(), and getFooterText().

However, this still leaves the body of the loop unresolved; what can we do about getting the data item for the current column? One approach would be to create a method called getDataItem (Object obj, int column), which takes the object currently iterated over and generates the corresponding data item for the column. This would work, but in my experience working with Object instances and then upcasting to the class we are interested in indicates that the design lacks something. In this case it's most natural to create an interface representing an object that can be exported:

public interface IExportableData {
public int getColumnCount(int column);
public String getTitle(int column);
public Color getColor(int column);
}

I can then create a PlanningTool.Data-Item object from an IExportableData object. There is now a design issue: Does the export of data fall under the responsibility of SalesInfo and PersonnelInfo, respectively? This depends on the specific applications; if it does fall under their responsibility, it's appropriate that the corresponding classes implement IExportableData directly. Otherwise it's more appropriate to create implementation classes of IExportableData (e.g., ExportableSalesInfo and Exportable PersonnelInfo), which, respectively, delegate to SalesInfo and Personnel Info. In this example I've chosen the former solution; for example, the new SalesInfo class can be seen in Listing 4.

With this interface in place, the last piece of domain-specific functionality is the retrieval of the list of data for the given domain. We create a hook for this that the implementations use to call the corresponding controller. For example, for SalesInfo:

protected List getDataForPeriod(
int startYear, int endYear) {
return new SalesController().
getSalesInfo(startYear, endYear);
}

After this refactoring, exportSales Info() contains no domain-specific code. The approach now is as follows:

1.  Create an abstract superclass (Abstract Exporter); domain-specific subclasses (SalesInfoExporter and PersonnelInfo- Exporter) should extend it.
2.  In the abstract superclass, create abstract methods for each hook (get Title(), getColumnCount(), getDataFor- Period(), and getFooterText()).
3.  Move the method (exportSalesInfo()) from the subclass to the superclass, possibly renaming to remove domain-specific connotations.

That's it!

AbstractExporter is shown in Listing 5 with the refactored SalesInfoExporter class.

Note that sometimes the renaming part in stage 3 might not be possible (for example, if a particular interface is to be implemented or preserved). In this case the method should just call the superclass method, as shown below:

public void exportSalesInfo(
int startYear, int endYear){
exportInfo(startYear, endYear);
}

This refactored design is a major improvement over the original one: there is now very little repetition, the separation of responsibilities is much clearer, and the code performing the export and the data to be exported are now loosely coupled.

One practical issue that often arises is that it isn't always possible to choose the superclass of a class; for example, if the class has to extend a specific superclass to fit into a particular framework. In this case we choose solution 3.

Solution 3: Delegation
This solution is very much a variation of solution 2 but instead of using inheritance, delegation is used. There are four steps.

First, an interface defining the hooks described in the previous section (lines 36–41 in Listing 5) should be created:

public interface IExporter {
public String getFooterText();
public List
getDataForPeriod(int startYear,
int endYear);
public String getTitle();
public int getNumberOfColumns();
}

Next, the classes SalesInfoExporter and PersonnelInfoExporter should implement this interface; the implementations from solution 2 (e.g., lines 46–59 in Listing 4) should be made public. The third step is that the abstract superclass from solution 2 should be concrete and have an IExporter instance variable. The hooks that were previously in this class should be removed, and calls to them replaced by calls to the corresponding methods on the IExporter instance variable. This is shown in Listing 6.

Finally, the export methods in SalesInfoExporter and PersonnelInfo- Exporter should create an instance of AbstractExporter and call its exportInfo() method. For example:

public void exportPersonnelInfo(
int startYear, int endYear){
new AbstractExporter(this).
exportInfo(startYear, endYear);
}

SalesInfoExporter and PersonnelInfoExporter could be further decoupled from AbstractExporter using an Inversion of Control pattern (see the list of references for more details). The idea behind solution 3 is exactly the same as solution 2. However, their structures differ according to whether inheritance or delegation is more suitable.

Refactoring
To quote Martin Fowler, "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure." In practice, this means taking something that works and improving its design so that it's easier to maintain, extend, debug, and so on. In this article I refer to a number of standard refactorings, details of which can be found at the refactoring Web site in the references list.

Template Method Pattern
The Template Method pattern is one of the original Gang of Four design patterns (Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, et al). This pattern captures common functionality in an abstract superclass, and domain-specific functionality is located in concrete methods in the subclass known as hooks. These hooks are defined as abstract methods in the superclass and can therefore be referred to from there. See the references at the end of the article for more information about this very useful pattern.

Closing Remarks
The techniques described in this article are practical ones that I have found useful on a number of projects. Copy-paste programming is easy and helps to provide something that works, fast. However, as soon as the first copy-paste phase is complete, it's important that the techniques described in this article are applied before the problem with repetition gets out of hand; the sooner the problem is addressed, the easier, quicker, and cheaper it is to resolve.

References