|
|
|
|
|
|
|
Notice that the record list object is an implementation-level object. This object is not readily apparent in the problem domain, yet we need it in order for the operation of sorting to make any sense. (Sort is not an operation on an individual personnel record; it is an operation on a list of records.) |
|
|
|
|
|
|
|
|
The second major step in OOD is to determine if there are any inheritance or composition relationships among the objects. Using is-a as a guide, we do not find any inheritance relationships. However, the record list object and the personnel record object clearly are related by composition. That is, a record list has-a personnel record within it (in fact, it probably contains many personnel records). Discovery of this relationship helps us as we proceed to design and implement each object. |
|
|
|
|
|
|
|
|
The masterFile Object: For the concrete representation of this object, we can use the ifstream class supplied by the standard library. Then the abstract operations of opening a file and reading data are naturally implemented by using the operations already provided by the ifstream class. |
|
|
|
|
|
|
|
|
The Personnel Record Object: We could implement this object by using a C++ class, hiding the data members as private data and supplying public operations for reading and writing the members. (Also, we might need to provide observer and transformer operations that retrieve and store the values of individual members.) Instead, let's treat this particular object as passive data (in the form of a struct with all members public) rather than as an active object with associated operations. We'll use the struct declarations shown earlier (AddressType and PersonnelData), and we can implement the reading and writing operations by using >> and <<operators to input and output individual members of the struct. |
|
|
|
|
|
|
|
|
The Record List Object: This object represents a list of personnel records. Thinking of a list as an ADT, we can use a C++ class to conceal the private data representation and provide public operations to read records into the list, sort the list, and print the list. |
|
|
|
|
|
|
|
|
To choose a concrete data representation for the list, we remember the composition relationship we proposednamely, that a record list is composed of one or more personnel record objects. Therefore, we could use a 1000-element array of PersonnelData structs, along with an integer variable to keep track of the length of the list. But there are two disadvantages to using an array of structs in this particular problem. |
|
|
|
|
|
|
|
|
First, the PersonnelData structs are quite large (600 bytes each). If we declare a 1000-element array of these structs, the compiler reserves 600,000 bytes of memory even though the input file may contain only a few records! |
|
|
|
|
|
|
|
|
Second, the act of sorting an array of structs can take a lot of time. Consider the selection sort we introduced in Chapter 12. In the SelSort function, the contents of two variables are swapped during each iteration. Swapping two simple variables is a fast operation. If large structs are being |
|
|
|
|
|