Is Schrödinger's Cat
Object-Oriented? - Chapter 4




IV. Classes, Hierarchies
And
Quantum Field Theories

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


Class View Quantum Physics
class quantum field
object (class instantiation) quanta
constructor creation operator
destructor annihilation operator




JavaTM is a trademark of Sun Microsystems, Inc.

Microsoft, Windows and Windows NT are registered trademarks of Microsoft Corporation.

Other companies, products, and service names may be trademarks or service marks of others.

Copyright    Trademark



  Java Education Java Home  
IBM HomeOrderEmployment