In the OM we think of objects as concrete entities that exist in space/time.
In contrast, a class is an abstraction which summarizes objects'
common properties (structure and behavior). Each object is always some
instance of a class. For example, the class TProton describes
all abstract properties shared by proton objects. The concrete object aProton
is an instance of the class TProton . Both, the OM and QP are
not only interested in describing a single object or particle but also
many mutually interacting ones. In this section we compare the OM and the
QP descriptions of systems of many identical objects. We also present a
design of the class TProton. In addition, using C++ notation,
we introduce several important OM concepts such as base and derived classes,
simple and multiple inheritance, and polymorphism.
Let us first discuss the QP description of a system of many identical
particles. Consider a system of two TIsingSpin objects labeled
anIsingSpinA and anIsingSpinB. Each one has, associated
with it, a 2-dimensional vector space E(a) and E(b), spanned
by the vectors up and down for both objects, anIsingSpinA and
anIsingSpinB. To the composite system corresponds a vector space
E = E(a) X E(b) (X indicates the direct product
of the two vector spaces E(a) and E(b)) spanned by four vectors
|A up> X |B up>, |A up> X |B down>, |A down>
X |B up>, |A down> X |B down>, corresponding to
all possible combinations of states of the spins A and B. Obviously, this
discussion is easy generalizable to many objects, say anIsingSpin(i)
with i=1,2,..., N. The composite system made of N objects of type (class)
TIsingSpin has, associated with it, a state vector space E,
the direct product of the individual state vector spaces E(i) for all i.
One-body operators, such as SetUpA(), only operate on anIsingSpinA
setting its state to up, but do not affect other objects. Mathematical
representations of a given vector depend on the choice of coordinates,
i.e., a vector has many possible representations. For a system of many
particles there is an alternative (equivalent) representation of the system's
state vector which does not hinge on the individual state vectors but focuses
on the system's properties such as total spin (sum of the spin of individual
particles), total number of particles, total energy/momentum,.... This
alternative representation of the same physics known as second quantization
[5]
is closely related to a "class view" in the object model. Although
second quantization is the preferred formulation of the non-relativist
quantum mechanical many-body problem, it is the only choice when the fully
relativistic extension is considered. This is because in the relativistic
view there cannot be a single (or a few) object simplification of reality
but there must always be a multitude of coexisting objects.
An important feature of the second quantization formalism is the
existence of the creation and annihilation operators. These operators,
are closely associated with the constructor and destructor operators common
in most OO languages (such as C++). In the second quantization formalism,
Proton becomes a quantum field. Associated to it, there is a creation
and an annihilation operator. Similarly, in the OM TProton
becomes a class. Associated to it, there are constructors and destructors.
Using C++ notation, the creation (constructor) and annihilation (destructor)
operators are denoted TProton() and ~TProton(), respectively.
[In C++ there can be several constructors.] State vectors are now associated
to systems with zero, one, two,..., particles (quanta) each in one of its
possible allowed states. The null particle system is known as the vacuum
(i.e., a class that has not been instantiated). Contrary to one's naive
expectation, the null particle state could be quite complex and its effects
may be observable.
Creation operators and constructors serve very similar purposes.
For example, in C++ one instantiates (creates and initializes) the class
TProton, creating an object (particle) of the class, which we
call aProton
TProton aProton;
In the QP language aProton is a one-particle state (a single
quantum of the Proton quantum field). The constructor above is the so-called
default constructor as it does not take any argument (it might use a random
number generator to select a value for the proton's momentum). Now suppose
that we would like to create another proton with a given momentum, aMomentum
= (aMomentumX, aMomentumY, aMomentumZ). We would then design a constructor
that takes an argument, i.e., the value of the momentum: aMomentum,
TProton bProton(aMomentum);
aMomentum is an object (real three dimensional
vector) of the class TVector3D. Before using it above, it might
be instantiated as follows
TVector3D aMomentum(aMomentumX,aMomentumY,aMomentumZ);
where TVector3D(x,y,z) is one of the constructors
of the class TVector3D and takes the three arguments in parenthesis
to be the values of the Cartesian components of the vector object to be
created (see Appendix A).
Constructors instantiate objects. Using the constructor we can instantiate
as many proton objects as desired. Suppose we would like to create an oxygen
nucleus system that contains eight protons and eight neutrons with arbitrary
(randomly chosen) momenta, we could proceed as follows
TProton aProton[8];
TNeutron aNeutron[8];
It is usual practice in C++ to declare a class, say TProton,
in a file called a header file while implementation of functionalities
is placed in one (or several) source files. Clients of TProton
usually will need the header file, Proton.h, (interface of TProton
with the exterior world), and seldom, if the design is correct, would information
about actual implementation be required. The declaration of the class TProton
follows
#include <Vector3D.h>
class TProton {
public:
TProton ();
TProton (TVector3D aMomentum);
virtual ~TProton ();
virtual void SetMomentum (TVector3D aMomentum);
virtual TVector3D GetMomentum ();
virtual long GetNumProtons ();
virtual double GetMass ();
virtual long GetElectricCharge ();
private:
static long fgNumber;
static const double kMass;
static const long kElectricCharge;
TVector3D fMomentum;
};
To accomplish information hiding, classes have public and
private members. (In fact, there are also protected members, as
discussed in the Appendix B). Members
include both data members (fgNumber, kMass ,...) and
member functions or methods (constructors/destructor, get/set methods,...).
Public members are accessible to any client that uses the class definition
(i.e., includes the header Proton.h describing TProton's interface).
[In turn, the class TProton is a client of TVector3D
since it uses objects of this type. Then, the header Vector3D.h (which
is given in the Appendix A) must be included
(first line of the above code) allowing TProton access to public
members of TVector3D.] The public members of the class TProton
are the constructors, the destructor and the set/get methods. Private members
can be accessed only by objects of the class, i.e., by protons. They are
hidden from other types of objects, such as electrons. Private data members
in the class TProton include the value of its mass, electric charge,
momentum, and the total number of protons. In the design above, we have
chosen to provide public access to the proton's private data through get
methods.
Static members act as a global class variables, i.e., all objects
of a particular class have access to the same variable. In the class TProton
, fgNumber , kMass and kElectricCharge are all
static. Besides this, the last two data members are also constant (const)
as these values are fixed for all protons. In contrast, fgNumber
changes as protons are created or destroyed. One of the weakness of this
design is that any proton object "knows" (i.e., can access) the
total proton number, fgNumber . Alternative TProton designs
are discussed in Appendix B. The private
data member fMomentum is an object of the class TVector3D.
It is not static as every object owns its own value for fMomentum
. Neither is it constant since this value changes as aProton object
interacts with other objects.
In Appendix B, we start at a higher
level of abstraction, defining the classes TParticle and TNucleon
. In that design (see Fig. 2) TNucleon directly derives from TParticle
, and in turn, TProton and TNeutron derive from TNucleon.
Inheritance is one of the fundamental characteristics of OO programming.
In C++, it is supported by the mechanism of class derivation. Derived
classes inherit properties (i.e., data members and member functions)
from the parent class (known as the base class). Derived classes
usually add new members and/or override methods (i.e., provide different
implementation). For example, TNucleon is a base class
relative to TProton and TNeutron .Then, implementation
of most functionalities required by derived classes (such as TProton
and TNeutron) is already provided by (inherited from) their base
class (TNucleon). In Appendix B
design, the class TProton only needs to override the constructors
and destructor, and to implement just an additional method: GetElectricCharge()
. Notice that the declaration of TProton in Appendix
B is much simpler than that presented above, as there we have taken
advantage of inheritance.

Figure 2. A possible class diagram of the particle "zoo"
displaying single inheritance relationship among classes. In this design,
TParticle and TChargedParticle are abstract base classes
(they cannot be instantiated), all other classes are concrete. Should TPion
and TNucleon derive directly from TParticle, or via TChargedParticle?
Should TQuasiParticle derive from TParticle, or be at
the top of the hierarchy in parallel to TParticle? In OO design
of complex systems, the class taxonomy is usually a highly non-trivial
problem.
At the highest level of the hierarchical structure (see, Figure
2) we define the class TParticle that encompasses properties shared
by all particles (e.g., fMomentum, SetMomentum(),GetMomentum()
...). This class is called abstract base class and is never instantiated.
That is, we never create quanta of TParticle, but only create
objects of its derived classes such as TProton, TElectron,
TPion,.... Nevertheless, abstract base classes are useful as they
serve to set a common protocol (common notation for all derived classes).
Figure 2 presents a possible single inheritance class diagram of
the particle "zoo". Protons are fermions (the value of the proton's
total spin is half-integer, i.e., 1/2); and they are also charged particles.
At higher levels of abstraction we might define the abstract base classes
TFermion and TChargedParticle. In this higher abstraction,
TProton would inherit from both base classes. This is an example
of multiple inheritance.
Inheritance is just one (although a very important one) of the possible
relationships among classes. It is also known as "kind of" relationship
since, say, TProton is a "kind of" TNucleon
. Another important class relationship in OO design is "part of".
For example, protons are made of three quarks. Then, aQuark[3],
an array of three quark objects, is "part of" a proton. For example,
a possible TProton class design might include
TQuark aQuark[3];
say, as a private data member. This design makes more explicit some
aspects of the proton's internal structure which may be required in some
problem domain. Which is the "best" class design and the "best"
class taxonomy? The answer strongly depends on the piece of reality we
try to capture and the questions we intent to address. These are some interesting
issues in OO design further discussed in Section
VI.
We now introduce polymorphism which we exploit in the coming section.
Polymorphism means that a single name may denote methods of many
different classes related by some common base class (these methods might
act differently on objects belonging to different classes). For example,
we might provide the method GetElectricCharge() in the class TChargedParticle
. A client's code then works correctly for, say, objects of the classes
TProton, TElectron, ..., (returning +1, -1, ...) which
derive from TChargedParticle even if the compiler only knows these
objects are of type TChargedParticle. That is, code works correctly
even if actual values of particles' electric charges are only known at
runtime. Polymorphism combines the features of inheritance with dynamic
binding (that is, the types of variables and expressions is not known until
runtime) and is one of the most important concepts in OO.
Finally, to conclude this section we summarize some of the analogies
between the OM ("class view") and quantum field theory.
TABLE 2. Classes and Quantum Fields