Re: Object Oriented?

[Len Olszewski <saslpo -at- UNX -dot- SAS -dot- COM>]

In article <4gfv8h$204 -at- homer -dot- alpha -dot- net>, Bob Morse <morse -at- globaldialog -dot- com>
writes:
|> "Susan W. Gallagher" <sgallagher -at- expersoft -dot- com> wrote:
|> >At 1:47 PM 2/20/96, Judith Hammeran wrote:
|> >[snip]
|> >>Can anyone give me a definition of "object oriented"? I'm starting to see
this
|> >>phrase  in a lot of job listings, and I don't have a clue what it means.
|> >>
|> >
|> >"Object Oriented" referrs to a programming paradigm -- .....
|>
|> My two cents:
|>    I think the OO "paradigm" is more aptly characterized as a "metaphor,"
and
|> personally I don't think it's a very good one.

[...]

|> If I strip away all the metaphor crap and just look at
|> encapsulation and inheritance, then it seems to makes sense, and I've had a
much easier
|> time learning the rest of the language.
|>   Well, okay, so it was a nickel (instead of two cents) .......

A lot of folks think the OO metaphor is oversold, Mr. Morse being the
most recent. As a programming paradigm, there are several principles in
OO which have their roots in structured programming, which in turn have
*their* roots in solid engineering principles, so in one sense there is
some truth in viewing the metaphor as a repackaging of proven
programming precepts (which counts as my alliteration for today).
Surely, extreme encapsulation, information hiding, and polymorphism are
just richer expressions of what we called "modularity" back in the days we
wrote "subroutines".

The true usefulness of the OO metaphor, IMHO, becomes more apparent if
you use it throughout the analysis (problem definition), design
(solution definition) *and* implementation (programming) phases of a
software development cycle. Using well-defined methods for each step,
you discover that the method of expression in all three phases is
exactly the same. The idea (the so-called "round-trip gestalt") is that
OO anticipates the inevitable need to re-evaluate analysis and design
*during* implementation to code around some unforeseen problem.  The OO
metaphor accomodates this. So when you change your code, you can easily
change your design and analysis to support it as well. That's the
theory, at least. How well you do it causes your mileage to vary some.

Commercially, OO is a buzzword used to emphasize easy reuse of modules
to customers, and also to cure halitosis and improve your love life.
This, I agree, is garbage.

OO principles, however, are pretty solid if you look at them as an
effective way to frame an entire software development cycle. I advise
reading the literature or taking coursework, as Mr. Morse has done, to
make sure you know how to use the terminology accurately. The
terminology *is* confusing, and it trips up many TW'ers, and *that*
causes a lot of needless mushiness in tecnical doc.

Cordially,
--
Len Olszewski           My opinions; you go get your own.
saslpo -at- unx -dot- sas -dot- com