Prefactoring

8.9. A Little Prefactoring

We modified the design as the code was being written. The following prefactoring guidelines suggested these modifications.

8.9.1. Splitters Versus Lumpers

The com.samscdrental.importexport package contains classes related to importing the data from text files:

    AddFromFileInterface.java
    CDDiscDataAccessImportExport.java
    CDDiscImportExport.java
    CDReleaseDataAccessImportExport.java
    CDReleaseImportExport.java
    CustomerDataAccesstExport.java
    CustomerImportExport.java
    DataAccessImportExportHelper.java

Tim and I originally started to place the method to import data from a file in each collection class, such as CustomerDataAccess. If the external representation of the data changed, the method in each class would have to change. Taking the "Split Versus Lump" approach, the import methods were separated into their own classes (e.g., CustomerDataAccessImportExport). Each class with an external representation (e.g., Customer) has a corresponding class (CustomerImportExport) that contains the import method (parseLine( )).

The data file format is one object per line. Each line contains the attribute values separated by a vertical bar (|). The collection class, such as CustomerDataAccessImportExport, reads the lines and handles file-oriented errors. The corresponding CustomerImportExport class parses each line and deals with attribute value errors.

8.9.2. Adopt a Prefactoring Attitude

The collections are made persistent using Java object serialization. The stored ...