Prefactoring

8.11. Sometimes Practice Does Not Match Theory

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