Page 355 - Introduction to Programming with Java: A Problem Solving Approach

The second-cut version of the Square program contains stub implementations for the drawHorizontalLine and drawSides methods. Now, we need to replace those stub methods with actual methods. Figures 8.9a and 8.9b contain our final version Square class. The only new items are the drawHorizontalLine and drawSides methods, which are straightforward. We encourage you to study their implementations on your own in Figure 8.9b.
Top-Down-Design Downside
Almost every human-designed project must necessarily include some form of top-down thinking. However, pure top-down design has some undesirable side effects. One such side effect is that subordinate modules tend to be overly specialized. A well-known and particularly egregious example of how the top-down way of thinking can lead to excessive specialization is the case of the $660 Pentagon ashtrays. The Pentagon (headquarters of the United States Department of Defense) hired a large military contractor to manufacture ashtrays for Pentagon use. Since compatibility is important for many military components, the military generally wants faithful adherence to its specifications, and contractors naturally develop procedures and attitudes that promote conformity. However, sometimes there can be too much of a good thing. The ashtrays conformed perfectly to their specification, but each one had a price of $660. Top-down design went to a ri- diculous extreme. Even though some of the top-level specifications may have been unconventional, the con- tractor probably followed the standard operating procedure and tried to match them perfectly. Hypothetical quote from the contractor’s marketing manager: “What was specified did not match anything that was avail- able, so we had to make it by hand in the machine shop.”
You may be thinking—Interesting story, but how do the $660 ashtrays relate to programming? The
8.7 Bottom-Up Design
Now, let’s look at the logical opposite of top-down design—bottom-up design. Bottom-up design imple- ments specific low-level tasks first. To apply bottom-up design to the Square program, you might imple- ment a drawSolidSquare method first. Next, you might implement a drawBorderSquare method. After finishing these bottom-level methods, you would implement higher-level methods, which are in charge of more general tasks, like a draw method to draw either type of square—a solid square or a border square.
As you implement each program component, you should test it immediately with a custom driver that’s tailored to that particular component. You won’t need any stubs, since already-tested lower-level methods will be available to be called by whatever higher-level method you are currently testing.
For simple programs like many of those that appear throughout the body of this book, bottom-up design is an appropriate strategy to use because it allows you to focus quickly on the essence of whatever problem is currently most critical, and it allows you to defer presentation details until later. For an example of bottom up design, look at any program in this book in which we present a driven class before we present a driver
Apago PDF Enhancer
top-down philosophy can lead to inefficient development practices. In the extreme case, that philosophy led to the military contractor expending enormous effort on the design and manufacture of something as sim- ple as an ashtray. In general, the top-down design philosophy can motivate people to “reinvent the wheel.” This tends to increase overall product cost. It also tends to reduce the reliability of the final product. Why? Because with everything being new or reinvented, there’s no past history of testing and debugging to rely on.
8.7 Bottom-UpDesign 321