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

8.6 Top-Down Design 313 each solution “step” is a refined version of a previous solution step. After implementing top-level tasks, the
programmer goes back and refines the solution by implementing the subtasks at the next lower levels.
Benefits of Using Top-Down Design
In top-down design, the designer doesn’t worry initially about the details of subtask implementation. The designer focuses on the “big picture” first. Because it focuses on the big picture first, top-down design is good at getting a project going in the right direction. That helps to ensure that the completed program matches the original specifications.
Top-down design is particularly appropriate when a project involves many programmers. Its early em- phasis on the big picture forces the project’s programmers to agree on common goals. Its strong organiza- tional emphasis promotes coherence and prevents the project from splintering off in different directions. The top-down design methodology facilitates tight managerial control.
Square Program Example: First-Cut Version
Let’s now apply the top-down design methodology to a simple example. We’ll implement a Square class such that each Square object can:
• Initializethesquare’swidth.
• Calculate and return its area.
• Drawitselfwithasterisksusingeitheranasterisksborderorasolidpatternofasterisks.
Each time the square is drawn, the user is prompted as to whether he/she would like a border format or a solid format, like one of these:
Apago PDF Enhancer
border-format square solid-format square width = 6 width = 4
Devise a way to solve the problem.
Using the above top-down design guidelines, the first step is to decide on the classes. In this simple example, it’s easy to identify all the classes right at the start—SquareDriver and Square. The next step is to decide on the instance variables. They should be a minimum definitive set of object properties—state vari- ables. All you need to specify a square is one number. The typical number that people use is the width. So we’ll use width as our lone instance variable.
But what about the square’s area? Area is a property, but it’s a simple function of width: area equals width squared. Since we can easily calculate area from width, it would be redundant to include area as another state variable. In principle, we could use area as the only state variable, and calculate width as the square root of area any time we needed width. But computing the square root is more difficult than computing the square, and we would frequently end up with a non-integer value for width, which would be hard to display in our prescribed asterisk format. So, for our problem, it’s a better strategy to use width as the lone instance variable.
What about the solidness of the square? This is a conceptual choice. If you want to
think of solidness as an inherent property of Square-class objects, it’s appropriate to create anotherinstancevariablelikeboolean solid.Ontheotherhand,ifyouwanttothink
of solidness as just a temporary display option, solidness should not have state-variable status and it should
Identify state variables.