< Day Day Up > |
If one has unlimited time and an unlimited budget, one might be able to make everything perfect. However, one is always limited in both dimensions. In respect to these restrictions, Tim and I left a few implementation issues outstanding.
8.11.1. Unintended CouplingTim and I did have to change the classes because of the way we stored them. This was not a major change, but one that had ramifications throughout the system. The collection classes were implemented using Java serialization. Thus, all of the data types had to implement Serializable . If the data had been kept in a database, this would not have been necessary. Sometimes implementation does affect the class definitions of upper-level classes. We could have created a separate persistence class for each data class to restrict this change to only the persistence classes. The extra work in this instance would not necessarily result in any extra benefit. 8.11.2. Nothing Is PerfectPrefactoring eliminates some refactoring, but it does not eliminate all of it. You will never see everything in advance. When writing the classes that perform the import of data from a file (e.g., CustomerDataAccessImportExport) ), I found myself cutting and pasting an entire method ( addCustomersFromFile( ) ) and modifying it for each collection. I knew it was wrong. I disregarded the "Adapt a Prefactoring Attitude" guideline. Developing a template or a preprocessing script to create this common code would have been a far superior solution. The version of Java used to develop the program did not support templates. A preprocessing script should have been written to avoid the duplication. It was quick to copy the code that worked and perform the few modifications that were required. I justified this because readers who wanted to run the program would have to have the same scripting language installed on their computers. However, the code works. If necessary, it can be refactored (or left as an exercise to the reader). Time and resource criteria often rank among the most critical factors in development choices and must be respected as valid engineering constraints.
8.11.3. There's Always an ExceptionThe following shows a combined operation: collectionsInitialize( String customerFilename, String cdDiscFilename, String cdReleaseFilename) This method really should be three separate methods that allow separate initialization of each file. The code is an example of getting lazy. Unless it is expected that the three must be initialized at once, the method should be "Split Rather Than Lumped." 8.11.4. A Little MisunderstandingAfter Tim and I had the system coded, we recognized we used two terms interchangeably that really did not mean the same thing. They were late and overdue . The two words show up as synonyms in Microsoft Word 's pop-up box. In relationship to this system, they really had two different meanings. A rental is "overdue" if it has not been returned by the due_date . The due_date is the start_date plus the rental_period . A rental is "late" if it has been returned and the end_date is greater than the due_date . We make a note of this violation of "A Rose by Any Other Name Is Not a Rose." Before continuing development, we will examine every instance of overdue and late and ensure that they have been applied correctly. To separate out the two terms, we will describe them as OverdueRental and LateReturnOfRental. The extra words clearly differentiate the meaning.
|
< Day Day Up > |