|
|
|
|
|
|
|
Which of these two representations is better? The second one is better for two reasons. |
|
|
|
|
|
|
|
|
First, it groups elements together logically. The statistics and the dates are entities within themselves. We may want to have a date or a machine history in another record structure. If we define the dates and statistics only within MachineRec (as in the first structure), we would have to define them again for every other data structure that needs them, giving us multiple definitions of the same logical entity. |
|
|
|
|
|
|
|
|
Second, the details of the entities (statistics and dates) are pushed down to a lower level in the second structure. The principle of deferring details to as low a level as possible should be applied to designing data structures as well as to designing algorithms. How a machine history or a date is represented is not relevant to our concept of a machine record, so the details need not be specified until it is time to write the algorithms to manipulate those members. |
|
|
|
|
|
|
|
|
Pushing the implementation details of a data type to a lower level separates the logical description from the implementation. This concept is analogous to control abstraction, which we discussed in Chapter 8. The separation of the logical properties of a data type from its implementation details is called data abstraction, which is a goal of effective programming and the foundation upon which abstract data types are built. (We introduced the concept of abstract data types briefly in Chapter 12 and explore them more fully in Chapter 15.) |
|
|
|
 |
|
|
|
|
Data Abstraction The separation of a data type's logical properties from its implementation. |
|
|
|
|
|
|
|
|
Eventually, all the logical properties have to be defined in terms of concrete data types and routines written to manipulate them. If the implementation is properly designed, we can use the same routines to manipulate the structure in a wide variety of applications. For example, if we have a routine to compare dates, that routine can be used to compare dates representing days on which equipment was bought or maintained, or dates representing people's birthdays. The concept of designing a low-level structure and writing routines to manipulate it is the basis for C++ class types, which we examine in Chapter 15. |
|
|
|
|
|
|
|
|
Style Considerations in Choice of Data Structure |
|
|
|
|
|
|
|
|
Just as there are style considerations in writing programs, there are also style considerations in choosing data structures. A program can produce a correct answer, but if it is difficult to debug, read, or modify, it can still be a poor |
|
|
|
|
|