eliminates code duplication for common tasks in a
natural and intuitive way. The inheritance mecha-
nism is built into the C++ language and therefore re-
quires no enforcement by or special discipline from
the programmer.
Figure 2 intentionally shows only the major class
types, in accord with the introductory nature appro-
priate to this Chapter. It is a simple matter to derive
further specialized classes from the base classes
shown. For example, one would derive a VikingOr-
biter from OrbiterPlatform.
2.3. Observation Types.
The various observation data types fall naturally
into the two broad categories, timing (in a sense, the
radial coordinate from the observer) and positions
(on the sky, i.e. transverse to the radial direction).
The complete breakdown is as follows:
I.
Transverse (position)
A.
Optical observations
1.
Global positions
i.
Transit circle
2.
Differential positions
3.
Occultations
i.
Satellite-planet
ii.
Star-planet
iii.
Spacecraft-planet
4.
Transits
i.
Solar
ii.
Planetary
B.
VLBI
II.
Radial (timing)
A.
Doppler observations
1.
One-way
i.
Pulsars
ii.
Spacecraft
2.
Two-way
i.
Radar
ii.
Spacecraft
B.
Time delay observations
1.
LLR
2.
Radar
i.
Differential radar
ii.
Radar closure
3.
Spacecraft
i.
Single
ii.
Multi
For reasons having mainly to do with datasets
that are currently insufficiently large or insufficiently
accurate to have a substantial effect on ephemeris ac-
curacy, early versions of Newcomb will not include
the observation types shown in
light red
. Because
extensibility is built into the design of Newcomb,
adding further capabilities as they become necessary
will involve minimal effort -- there is no need, from
a maintenance standpoint, to include capabilities that
are anticipated to go unused for a long time. That is,
with a good object oriented design we do not have to
worry so much about "making room" for anticipated
future capabilities. Figure 3 shows the proposed
class hierarchy.
Each type of input data stream will contain em-
bedded type information, and instantiations of the ap-
propriate data objects will handle the data. The
specific objects shown in Figure 3 encapsulate not
only the corresponding observational data but also
the functionality required to reduce that data type.
For example, notice that all datatype objects have,
via inheritance from the base class Observation,
platform information and the ability to handle (say)
aberration.
As with Figure 2, Figure 3 is intentionally not
complete, especially regarding encapsulated data and
method details. However, all the important base
classes, and their inheritance dependencies, are
shown.
Chapter 2: Observations
D:\Newcomb\Documentation\NewcombManual.lwp
7 of 19
10:42pm April 23, 1997
