|
|
|
|
|
|
|
The second major step in OOD is to determine the relationships among the objects. Specifically, we're looking for inheritance and composition relationships. Our object table does not reveal any inheritance relationships. Using is-a as a guide, we cannot say that a time card is a kind of time stamp or vice versa, that a time card list is a kind of time card or vice versa, and so on. However, we find several composition relationships. Using has-a as a guide, we see that a time card has a time stamp as part of its state, a time card has an ID number as part of its state, and a time card list has several time cards as part of its state (see Figure 16-9). Discovery of these relationships helps us to further refine the design (and implementation) of the objects. |
|
|
|
|
|
|
|
|
Now that we have determined a reasonable set of objects and operations, let's look at each object in detail. Keep in mind that the decisions we have made are not necessarily final. We may change our minds as we proceed, perhaps adding and deleting objects and operations as we focus in on a solution. Remember that OOD is an iterative process, characterized by experimentation and revision. |
|
|
|
|
|
|
|
|
The punchInFile Object: This object represents an ordinary kind of input file with the ordinary operations of opening the file and reading from the file. No further design of this object is necessary. To implement the object, the obvious choice for a data representation is the ifstream class supplied by the C++ standard library. The ifstream class provides operations for opening and reading from a file, so we don't need to implement these operations ourselves. |
|
|
|
|
|
|
|
|
The ID Number Object: This object merely represents an integer number (possibly large), and the only abstract operations we have identified are |
|
|
|
|
|
|
|
|
Figure 16-9
Composition Relationships Among Objects |
|
|
|
|
|
