It is often said that a picture is worth a thousand words. A prototype is like a picture. A user interface described in text is often harder for the customer to visualize than the same interface described with a diagram or picture. Use cases can provide excellent textual descriptions. A prototype (or screen mockup) gives a more concrete perspective on a program's intended operation. The prototype can spark feedback from the client in both the program's operation and in missing requirements.

DON'T THROW AWAY INFORMATION

When I was presenting these prefactoring guidelines in a talk at the Software Development Conference, Jerry Weinberg made an interesting observation about some of the guidelines in this chapter. He stated that they revolve around the central principle of not throwing away information. For example, describing a price as a double, rather than as a Dollar, decreases the information about the price. Lumping a group of concepts into a single class, rather than splitting them into multiple classes, hides information. Now, if I only could have convinced my mother that my comic book collection was really information...

One of the dangers of making a perfect-looking GUI for a prototype is that the interface represents the program to the user. If the interface is complete, the user might expect that the system is almost complete. Some user interface experts suggest that interfaces be designed using whiteboards or Post-it notes. If you are programming in Java, you can use the Napkin Look and Feel (http://napkinlaf.sourceforge.net/). Tim and I created a rough-draft prototype of the screens for the uses cases we worked on with Sam (Figure 2-1). We went

Figure 2-1.  Rental screens

over it with Sam. The cases are simple, so he had no changes in its interface. He did note that the buttons should use a large font so that he could read them without his glasses.

PROTOTYPES ARE WORTH A THOUSAND WORDS

A picture of an interface, such as a screen, can be more powerful than just a description.

* For further information on use cases, see Writing Effective Use Cases by Alistair Cockburn (Addison-Wesley Professional, 2000).

* Finding existing solutions can be problematic. Sometimes it can be hard to describe the solution you seek in such a way that Google™ can find a match.

† See Software Tools by Brian W. Kernighan (Addison-Wesley Professional, 1976) for the earliest discussion I have found on the issue of using tools to create solutions.

* See http://www.literateprogramming.com/ for a discussion of names.

* Not all objects have behavior. Objects that contain just data (sometimes called data transfer objects) are useful in interfacing with GUI classes and passing as objects between networked systems. Data
transfer objects are covered in Chapter 7.

† One reviewer notes that clumping without a responsibility definition for the class can lead to datapolluted classes. Clumping should also involve assigning operations to the clumped concept.

* Once upon a time, Montana had no speed limit other than “reasonable speed.” The upper limit still could be a reasonable number (e.g., 200).

† For an article on strong testing with languages that have implicit typing, see http://www.artima.com/
weblogs/viewpost.jsp?thread=4639.

* Michael Green, a reviewer, called this principle “No magic numbers!” after having to deal with numbers that could not be changed or removed (without negative side effects in apparently unrelated
code). He could find no one who knew what they were for or why they were there.