Data Structures in Program Design

Suppose you are handed a programming task that is very large, and no single step seems to solve it. Where do you begin? Programmers face this situation constantly, and it is the situation that top-down programming was developed to handle. The method makes a large task manageable by starting with the complete problem and dividing it into smaller jobs.

The important movement is from broad to specific. The programmer first decides what major work the system must perform, then refines each part. Each refinement pass produces smaller pieces that are easier to reason about than the original whole. The method does not claim that every programming problem has one perfect breakdown. Its value is that it gives the programmer a practical way to organize a large problem.

The diagram shows only the first split. In practice, each major job is divided again, and that division continues until a piece is simple enough to solve directly. Notice that the diagram describes the work to be done. It says nothing yet about how the program's information is organized, a point the rest of this article develops.

The source describes a program that must manage a collection of event registrations. Follow how a top-down plan would handle it, one step at a time.

Top-down programming is not presented as a bad method. It is a valuable and often-used way to solve problems. Its limitation is narrower than it might first appear. The method concentrates mainly on the instructions needed to solve the problem, and that focus can leave another design question underdeveloped: what data the program must manipulate and how that data should be organized. The limitation is not that decomposition is useless. It is that decomposition alone can give inadequate attention to data structures.

A top-down plan is usable before it is finished. Once the major jobs are identified, the programmer already has a structure to work from, and each refinement pass makes the next piece easier to handle. What the method does not guarantee is that the data side of the design has received equal attention.

The concept map makes the central point of the source visible. Subroutines describe organized pieces of work, control structures describe how that work proceeds, and data structures describe the data that the program manipulates. A design that plans only the first two areas can contain detailed instructions without an equally deliberate data design.

The registration plan from earlier illustrates the gap. Re-examine what it covered and what it missed.

A second limitation appears when work from one project must support another. Strict top-down programming begins with a particular problem and divides that problem into pieces that are convenient for that situation. As a result, the final design tends to be specific to the original problem. A large portion of it may not fit a different project without extensive modification.

Reuse matters because producing high-quality programs is difficult and expensive. Programmers and the people who employ them therefore have a strong reason to reuse work that has already been produced. A design tightly fitted to one problem makes that goal harder to achieve.

The comparison points to the specific features that block reuse. The design is shaped by the original problem from the first division onward. Each piece is convenient for that one situation, so the pieces carry the original problem's shape into any new project. Reuse becomes a matter of extensive modification rather than straightforward transfer.