Hi Sarah,

Replying to a message of Sarah Nunez to David Noon:

 SN> What I was taught was top-down, structured, modular programming.

OOD is bottom-up, so it is quite different from the DDH (Dahl, Dijkstra
& Hoare) approach to structured programming that arose about 30 years
ago.

 SN> (This was back in the dark ages of COBOL, but I've tried to translate
 SN> the concepts as much as I could to programming in other languages
 SN> such as BASIC, 360/370 Assembler, Fortran, and C.)

COBOL is probably the worst place to start, especially with dialects prior
to COBOL 85. It was so lacking in structuring syntax that it was truly
abysmal. FORTRAN IV was almost as bad, but FORTRAN 77 was a little better.

 SN>  Kludges and
 SN> spaghetti code were anathema, and I was taught to comment the heck
 SN> out of everything (not fun when you're punching IBM cards--I'd rather
 SN> clean toilets for a living than punch IBM cards again!).

I have about 30,000 Hollerith cards in my garage, many with IBM 360
assembler source code that I wrote circa 1973, or FORTRAN IV that I wrote
circa 1972.

 SN> I guess for starters, what's the difference between OOP and modular
 SN> programming? (We can take this to OS2PROG if you'd rather. . .)

Modular design and OOD are different approaches that can produce radically
different final implementations.

Modular design concentrates on breaking the function of the final software
into manageably small modules, each of which is developed and debugged
(hopefully) stand-alone. [I qualified this with "hopefully"
because so many FORTRAN programmers were in love with COMMON blocks, which
totally torpedo modular independence.] Unfortunately, this approach is
predicated on the assumption that all data entities are small,
easy-to-manage items, or can be handled on an element-by-element basis. In
languages such as FORTRAN or ALGOL 60, this assumption was well founded, as
these languages had no real facility for aggregating data in any way other
than homogeneous arrays. The assumption was not well founded in regard to
COBOL, which is why "structured COBOL" is usually far worse to
maintain than traditional "spaghetti bowl" COBOL (a.k.a.
SPAGBOL).

The only languages that facilitated productivity in a structured
programming environment were PL/I and ALGOL 68, as these introduced syntax
for the easy manipulation of heterogeneous data structures.

Object Oriented Design and Programming (OOD and OOP) take a largely
data-centric approach. The data structures that are to be manipulated are
identified and the data aggregates are formed based on relationships among
the elementary data items. Since data aggregates (we'll call them
"classes" from here on) are often quite similar but still
different, a design method arose for establishing relationships between
such classes. This allows one class to inherit many (or even all)
attributes from an already defined class, so that only the differences need
be further defined. This is called "subclassing", the derived
class is called a "subclass" and the earlier class is called a
"superclass".

Once all the classes have had their data structures defined, each one is
examined to see what functionality is required of it. Very few functions
are defined independently of data classes -- none at all in "purest of
the pure" OOP! These functions associated with classes are called
"methods". These look like ordinary functions in C or Classic
REXX, but they can be rather different semantically. Moreover, they are not
designed as part of a system, but as functional adjuncts to data
structures; they have no fixed place in a top-down calling hierarchy! They
can also be inherited by a class from its superclass, so creating a new
class can end up reusing a lot of source code; this has been the main
attraction managers have had for OOD/OOP.

There are other features too, but getting into OOP really requires one to
"think: data first, code later". I will try to expand on this and
provide sample code in OREXX over the coming weeks.

Regards

Dave


--- FleetStreet 1.25.1