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 values are read in the constructor of the collection and are written in the dispose( ) method.

Tim wrote the deserialization code and serialization code for CDDiscDataAccess . He realized he would need the same code for the other collection classes. He was tempted to cut and paste the code and do a little alteration. However, he followed the guideline "never cut and paste more than a single line." So even before testing commenced, the code was separated into a class of its own: DataAccessHelper .