|
|
|
|
|
|
|
and object-oriented design. These methodologies help you create solutions that can be easily implemented as C++ programs. The resulting programs are readable, understandable, and easy to debug and modify. |
|
|
|
|
|
|
|
|
The design technique we'll be using for the next several chapters is top-down design (it's also called structured design, stepwise refinement, and modular programming). It allows us to use the divide-and-conquer approach, which we talked about in Chapter 1. |
|
|
|
 |
|
|
|
|
Top-Down Design A technique for developing a program in which the problem is divided into more easily handled subproblems, the solutions of which create a solution to the overall problem. |
|
|
|
|
|
|
|
|
In top-down design, we work from the abstract (a list of the major steps in our solution) to the particular (algorithmic steps that can be translated directly into C++ code). You can also think of this as working from a high-level solution, leaving the details of implementation unspecified, down to a fully detailed solution. |
|
|
|
|
|
|
|
|
The easiest way to solve a problem is to give it to someone else and say, Solve this problem. This is the most abstract level of a problem solution: a single-statement solution that encompasses the entire problem without specifying any of the details of implementation. It's at this point that we programmers are called in. Our job is to turn the abstract solution into a concrete solution, a program. |
|
|
|
|
|
|
|
|
We start by breaking the solution into a series of major steps. In the process, we move to a lower level of abstractionthat is, some of the implementation details (but not too many) are now specified. Each of the major steps becomes an independent subproblem that we can work on separately. In a very large project, one person (the chief architect or team leader) formulates the subproblems and then gives them to other members of the programming team, saying, Solve this problem. In the case of a small project, we give the subproblems to ourselves. Then we choose one subproblem at a time and break it into another series of steps that, in turn, become smaller subproblems. The process continues until each subproblem cannot be divided further or has an obvious solution. |
|
|
|
|
|
|
|
|
Why do we work this way? Why not simply write out all of the details? Because it is much easier to focus on one problem at a time. For example, suppose you are working on a program to print out certain values and discover that you need a complex formula to calculate an appropriate field- |
|
|
|
|
|