6.6 Object-Oriented Implementation | 291Internal Data Representation
The first implementation step for a class is to decide on the internal representation of data.
Then we can use the means-ends analysis technique from Chapter 1 to design the algo-
rithms for translating between the abstract and internal representations. These algorithms
form the basis for the constructor and observer methods, as well as parts of some transformer
and iterator methods.
As we saw with our example of a Dateobject, the internal representation (Julian day) and
the abstract representation (month, day, year) can be quite different. In other cases, such as
the Nameclass, the internal representation may be exactly the same as the abstract form of
the data. We choose the internal form to be useful for the programmer rather than the user.
Our goal in selecting an internal representation should be to simplify our task and to
make the object efficient in terms of storage space and execution time. These goals some-
times come in conflict, and we must balance simplicity against efficiency.
Two problem-solving strategies that are valuable in designing the internal data repre-
sentation are looking for things that are familiar and solving by analogy. In the case of the
Dateclass, you can go to the library and research calendars. For the Nameclass, you already
know how to write a name.
Rarely will you have to invent an entirely new data representation. Most programs are
written to solve problems with which people have dealt in the past. Consider who would
normally use such data, and consult with those people or look in books that they would use
(Figure 6.8). For example, astronomers use dates in computing the positions of planets over
the centuries. You can find the formulas for computing the Julian day in some astronomy texts.
As another example, a geography professor gave an assignment to draw a map show-
ing nearby airports with their elevations and the lengths of their runways. Most students spent
hours poring through almanacs and topographic maps to gather the data. Even so, their
maps were inaccurate. One student, however, got a perfect grade because she stopped to
consider who would use such data. She went to a pilot supply shop and bought a precise map
of nearby airports. While there, she noticed a book that listed information for airports using
an especially efficient representation. If she ever had to develop a computerized version of
the map, she would start with that representation.
From the preceding discussion, it should be clear that we can’t give you a set of rules that
will automatically lead you to an internal data representation for a class. Each situation you
encounter is different. Be prepared to give this part of your design some careful thought, to
go to a library and do some research, to consult with other people, and to trade off issues of
efficiency and complexity.
Sometimes you may discover that no one representation is always best. Or there may not
be enough information to choose among several options. In those cases, you simply have to
pick a representation and use it. In the end, it may not turn out to be the best choice. But
remember the beauty of encapsulation—you can go back later and change to a better inter-
nal representation!
Now back to our Phoneclass. The CRC card for Phone assumed that the area code and
number would be kept as numeric values. These fields could just as easily be kept as strings.