Suppose we would like to design and implement an air traffic control
system. How to identify the key abstractions in the problem space? How
to identify classes and objects in an OO design? What are the possible
relationships among classes? Classes (such as TAirplanes , TRunways,...)
are static and their relationships are fixed before the execution of a
program. In contrast, objects (such as a new runway, new airplane...) are
dynamic. They are constantly created and destroyed during the lifetime
of a typical application. The identification of appropriate classes and
objects is the hardest problem of OO design[1-3]
In fact, in this section we identify analogies between OO design and the
problem of finding the "elementary components" of complex systems
(for example, superconductors). In many-body theory, this is the problem
of finding the effective Hamiltonian that describes the physics of interest.
At first glance, OO design may seem straightforward: just mimic the
objects of the outside world and their interactions, relevant to the piece
of reality to be captured in software. This is not the case in real OO
design. In general, reality is too complex to be fully captured in a design.
On the other hand, many of the outside objects/interactions may be totally
or partially irrelevant to our problem. For example, in a naive design
of a payroll one could include TEmployee objects, TCheck
objects, TPen objects, TInk objects, TBank objects,....
On the other hand, a more sound design might just introduce TEmployee
objects that pay themselves recognizing the irrelevance of other objects
such as aBank, anInk, aPen, etc. to the problem
of interest. In the process of abstraction, one "invents" a TEmployee
object with properties which do not correspond to those of a "real"
employee, but substantially simplifies the design. Moreover, to obtain
tractable and sound designs, one may introduce " abstract", "intangible",
or "totally imaginary" objects that "do not have any resemblance
to reality". For example, in a "computer graphics window"
design, one may use TAnimation objects (i.e., translation operators)
that move things around, and objects of the types TShape, TColor,
TSize ,... . In the design of a complex system one has to identify
key abstractions, propose some candidate classes and objects to mimic the
system, and conjecture some class taxonomy. Some of this has been briefly
discussed in Section IV.
What are observables? It depends on the observer's interest and ways
of probing the system. For example, given some TAirplane objects
in anAirport, one may be interested in either their size, color,
when they were built, airlines to which they belong, the number of available
seats, the type of engine, etc. Choosing the appropriate "degrees
of freedom" usually is a highly non-trivial exercise, and OO designs
depend critically on this choice. In QP one is confronted with similar
situations, for example, given a proton, its momentum might be the observable
of interest for some low energy experiments, at higher energies one may
be interested in the momenta of each quark. Alternatively, the proton's
spin may be one of the selected observables if interested, say, in the
hydrogen hyperfine structure. Or protons' degree of freedom may be totally
irrelevant, say, if describing hydrodynamic properties of water; even though
protons are "part of" water.
How does one identify "classes and objects" and their relationships
and interactions in Natural Sciences? The components of a system are usually
determined by how the system "breaks" under "minimal forces".
For example, oxygen gas is made of oxygen molecules. As we apply stronger
forces (at higher collision energy), molecules break down, and now the
system is made of oxygen atoms, ions and free electrons. Substantially
increasing the energy of our probes, we see our system composed of electrons,
protons and neutrons. At even higher collision energy one discovers that
protons and neutrons are made of quarks. This, again, is an illustration
of the hierarchical structure of Nature. "Minimal unit" is an
ambiguous concept that strongly depends on "context": depth of
penetration into the structure, physical conditions and phenomena to be
described (i.e., the kind of experiment selected to explore the system).
Given our oxygen gas at room temperature, we view it as composed of molecules
when interested in specific heat. On the other hand, if interested in,
say, electrical conductivity we instead regard the gas as made of positive
and negative ions.
One of the most basic problems of Physics is to "find" the
"fundamental objects" or "elementary components" of
complex systems. This problem is illustrated by superconductivity. Superconductors
are materials that offer almost no electrical resistance. Hence electrical
currents circulate for months with very little heat dissipation. Conduction
properties of metals can be explained in terms of interacting ion and electron
objects, but interactions among these type of objects cannot help explaining
superconductivity. Superconductivity was discovered in 1911, but it took
almost 50 years find a satisfactory theory. What are the relevant "objects"
to describe superconductivity"? The BCS (Bardeen, Cooper and Schriffer)
theory of superconductivity has shown that "the" sought "object"
is the so-called Cooper pair. A Cooper pair is an "atom" made
of two electrons that weakly attract each other (attraction mediated by
the host ions) and which behaves like a whole. This is an important point,
although "free" electrons repel each other (Cooper pairs cannot
exist in isolation from the material environment), in the appropriate environment
(inside a superconducting metal) they, indeed, form bound states and behave
as a whole identity. Cooper pairs are called quasiparticles, as they do
not exist in isolation. Quasiparticles, as animals, need their own habitats
to survive (e.g., superconductivity only occurs for a few metals in some
range of temperature, external fields,...). In contrast, protons and electrons
are particles. They can exist in freedom. The Cooper pairs (bosons) are
the carriers of electricity in a superconductor, and are much more effective
in their task (conducting electricity) than electrons (fermions), carriers
of electricity in normal metals.
How do we "solve" a complex many-body problem in physics?
Let us again discuss superconductivity. Given a metal made of ions and
electrons, one searches for the appropriate class or classes that capture
the physics of the problem. As reality is too complex, only essential features
can be incorporated if the model is to be mathematically (and/or computationally)
tractable. One hopes to write the so-called effective Hamiltonian Heff
of the system
Heff = H0 + HI ,
with H0 the free Hamiltonian containing the fields
(classes) relevant to our problem. For example, in the superconductivity
case, the class of interest is TCooperPair although naively, one
could have said that the "right" classes were TIon and
TElectron . The effective Hamiltonian is an operator, written
in terms of the TCooperPair creation and annihilation operators.
H0 describes a system of "non-interacting" Cooper pairs
(that is, there may be 0, 1, 2,... objects of the type TCooperPair).
The second term HI describes the TCooperPair interface,
that is how these objects interact among themselves, so it is called the
interaction Hamiltonian. Interaction is supposed to be weak for the effective
Hamiltonian to be meaningful, so the objects which encapsulate data (such
as mass, electric charge,...) and methods (such as SetMomentum()
, ...) conserve their identity as long as objects are in the proper habitat
(limit of validity of the effective Hamiltonian). Interactions describe
the object's interface with the rest of the world (outside view).
Object-Oriented design is facilitated by good class libraries. These
libraries provide the "atoms" or basic building blocks to be
used in our code. For example, for a linear algebra project, one may need
classes such as TVector, TMatrix ,.... The atoms are
not "rigid" units but quite flexible. The user can modify the
building blocks deriving his/her own classes from those provided (for example,
the user can change some methods, add new data members,...). Suppose the
class TMatrix is provided, but we need TSymmetricMatrix.
We just derive this class from TMatrix inheriting all its properties
and just adding the symmetry constraint (some relation among data members).
We do not need to implement, say, matrix multiplication as this operation
is inherited from the parent class, TMatrix. Then, design will
consist in using classes provided by the library (maybe after subclassing
some of them) in conjunction with other classes designed by the user. Finally,
the user interconnects all parts of the system.
If we would like to model, say, oxygen gas, it would be much more convenient
to have as fundamental building blocks molecules of oxygen (and maybe oxygen
atoms and ions) with the proper interactions, than, say, quarks and leptons
interacting via weak, electromagnetic and strong forces, or protons and
electrons interacting electromagnetically. In fact, had we started with
quarks and leptons, we may have never accomplished our project as it is
an immensely more difficult problem than if one starts with the "right"
building blocks. Frameworks in the OO technology are the analog
to the "complete design" of the oxygen gas using oxygen molecules
building blocks (and possibly oxygen atoms and ions) interacting via van
der Walls forces (and possibly electromagnetic ones), and, maybe, confined
to some container with some geometry and boundary conditions. Frameworks
encapsulate "collective behavior". This "collective behavior"
is the result of several classes interacting in a particular well-defined
manner. On the other hand, frameworks are not canned programs but flexible
designs. For example, we could add additional particles, new particle
types, modify or add new interactions, change the container geometry and/or
boundary conditions,... by subclassing and overriding. Frameworks are a
very natural way to reuse higher level designs. In conclusion, the difficult
problem of modeling a complex system could be substantially reduced by
good class libraries and frameworks. We will elaborate more on this point
in the last section.