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




VI. Object-Oriented Design
And
Effective Hamiltonians. Frameworks

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.




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