I am interested in aspects of OO programming for technical applications.

Technical equipment consists of several basic subsystems. In programming terms,
those subsystems have data structures and methods. Object oriented modeling is
data-oriented, in addition to procedure- oriented (calculation methods). In
classic programming style, the calculation method is central and the
surroundings are adapted (input/ output) to make the calculation work. The
advantage is, that this method is really straightforward and easy to comprehend.
The problem with it is that a different calculation method for the same
equipment will require extensive rewriting of the program, because the data
structure is adapted to a certain calculation method.

The theory is, that by adapting the data structure to equipment components, it
can be described in less variant terms that relate to real world entities. All
similarities in methods and data structures should be completely factored out.
This benefits both maintainability and flexibility. Technical equipment will
always consist of real and virtual components such as for example construction
elements or energy balances. Those will never change and they form a better
basis for a program. The essence is to decompose the equipment into a small
number of fundamental and universal components (objects).

This does however not really require an object oriented language. Such a
language may offer suitable constructs that facilitate implementation, at the
price of a more complex language. Inheritance and polymorphism can be used
adequately and elegantly in situations like graphics or user interfaces. The
application of OO programming techniques to user interfaces, operating systems,
matrix algebra, complex numbers and graphics are relatively easy to understand
and is well-documented. An excellent article which is I think well known is of
Decyk, Norton and Szymansky: "Introduction to OO concepts using fortran 90". It
explains several OO constructs in fortran 90 in a physical context.

For technical calculations, derived data types are useful to group data of an
object together. Modules are also a useful concept of fortran 90. I find it
difficult to see applications for inheritance (a top-down approach) in technical
applications other than some sort of trivial and unnecessary classification.
Polymorphism may require introduction of differences between calls of alternate
methods which look artificial instead of elegant. Technical equipment can be
described rather as an aggregation of a large number of simple, well understood
subsystems. I do not see any advantages of a container class over the classical
calling tree of subroutines because the aggregations vary too much. Am I missing
something? The actual calculation algorithms will not change much, if at all,
compared to non OO. They could be wrapped if necessary. These views might be
disputable, but may also illustrate some difficulties in the application of OO
methods in technical and physical problems.

An object oriented language does not help with the fundamental physical,
mathematical and logical analysis of the problem at hand. These analyses require
a sharp mind and sufficient insight in all involved areas to organize all the
interdisciplinary fields into data structures, methods and program logic. This
is in my opinion the real bottleneck in designing computer programs that work
and it is very difficult and it takes a long time to do.

OO languages generally are (much) more complex than those that are not OO. They
provide a number of relatively new structuring methods. If the application is
not properly understood, the result using an OO language is probably worse than
without. If the problem is however understood and factored properly, the claimed
advantages of reusability can come to bear. The added structuring methods can
express a better overview and thus could allow tackling tougher problems.
However, many of these can also be achieved without use of an OO language.

It is possible that for the often much more complicated technical and physical
applications, problem analysis lags behind the possibilities of OO programming
languages. It could also be, that inheritance and polymorphism are principally
unsuited for technical problems because those do not fit these concepts very
well. That would be worse. These considerations are of course important for the
development of a computer language for technical calculations. Has anybody ideas
about this? For the time being a pragmatic approach seems most fruitful and one
could use only those aspects of OO, that really contribute to a better program
structure and use the simplest language that does the job.


Michael Janeschitz-Kriegl
ABB Lummus Heat Transfer, Oostduinlaan 75, 2596JJ Den Haag, The Netherlands

e-mail: [log in to unmask]

My views are not necessarily those of ABB LHT




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%