8.11. Sometimes Practice Does Not Match Theory

 <  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.

CONSIDER THE USER

I once worked in a building in which the air conditioning system could not be controlled easily. Some offices were just the right temperature, and others were bitter cold. Some of the office inhabitants stuck cardboard covers over the air vents in their cold offices, causing the other offices that were cold to become even colder. Meanwhile, the maintenance workers were busy applying several layers of wax to a lobby floor that was not used due to the placement of the parking lots in relationship to the entrance . The architect was trying to win an architectural award, but he failed miserably at creating a livable office space. He never got feedback from his users, the office inhabitants.


8.11.1. Unintended Coupling

Tim 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 Perfect

Prefactoring 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.

NOTHING IS PERFECT

There is usually a better solution, but you can stop with good enough . [*]


[*] James Bach has an article on "Good Enough Testing" at http://www.satisfice.com/articles.shtml. See also http://www.agilemodeling.com/ essays /barelyGoodEnough.html.

8.11.3. There's Always an Exception

The 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 Misunderstanding

After 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.

ARE WE THERE YET?

We were driving with some friends to New York City. To provide some entertainment on the trip, the driver suggested that we bet on the exact time we would arrive in New York. Being the computer person, I said we had to agree on an exact definition of what arrival meant so that we could determine who won. I suggested that the moment the driver handed the toll to the toll taker at the Lincoln Tunnel would be the moment of arrival. We all agreed on this definition.

When we arrived at the Lincoln Tunnel, there was a backup at the tollbooth. The driver thought he was running a little late for the time that he bet as the winner. (We had covered the car's clock and removed all watches .) The lane next to us was empty, so he shifted over to that lane and pulled up to the booth. It was an automated pass booth , the kind where they read a bar code on your car. There was no attendant to hand the money to. He yelled out to the attendant in the next tollbooth, but she could not take his money. So he drove on through.

Now, by our definition, we never arrived in New York City. A clear definition helped avoid ambiguity and argument over who had won.

(One reviewer suggested that the person who had chosen the latest time could be perceived the winner. That person would be closest to the time that we next paid money to a toll taker at the Lincoln Tunnel. Of course, losers would want to take the Holland Tunnel instead.)


 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net