TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
"Susan W. Gallagher" <sgallagher -at- expersoft -dot- com> wrote:
>At 1:47 PM 2/20/96, Judith Hammeran wrote:
>>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. It suggests more power and magic than
is really there. The essence of OO is that the programming code is bundled into
self-contained modules (the "objects") that are then mixed-and-matched as needed for
the task at hand. The great benefit of OO to developers lies in the "black box"
metaphor, inasmuch as each "object" is a "black box" in which certain well-specified
functions are implemented, but the methodologies (and often most of the data as well)
are hidden from any external calling code. This permits the segregation and efficient
distribution of programming tasks among multiple programming team members. Nobody else
knows or cares HOW my "object" does what it does, as long as it does what I SAY it
does. So a dozen programmers can implement a dozen different objects however they like
(as long as they perform as advertised), and then somebody else can collect them all
into a single program that draws on the different objects' functionalities as needed.
Now, about the OO metaphore: An "object" can be just about any damned thing you
want it to be: arbitrarily defined, and to which "attributes" and "behaviors" are
arbitrarily ascribed. Objects are said to "know" things, and to "do" things. Bah!
Nonsense! Poppycock! Balderdash!
I don't mind taking a leap of faith on a good abstraction now and then, and I fully
understand and appreciate the value of encapsulation and inheritance, but I just don't
think that the metaphor is a very good abstraction. It seems to be a pointless
pathetic fallacy--an illogical personification of inanimate nonsentient objects like
"dates," "lists," blah, blah, blah. A "date" doesn't "know" or "do" ANYthing! In
fact, after struggling through an intro C++ class to absorb the significance of the
metaphor, I pretty much concluded that it's WORSE than pointless, because it's
misleading and distracting. 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) .......