Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!asuvax!stjhmc!p88.f15.n300.z1.fidonet.org!Lawson.English
From: Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English)
Newsgroups: comp.sys.mac.programmer
Subject: Re: OOP--What do you think?
Message-ID: <7823.280F0E45@stjhmc.fidonet.org>
Date: 16 Apr 91 13:56:52 GMT
Sender: ufgate@stjhmc.fidonet.org (newsout1.26)
Organization: FidoNet node 1:300/15.88 - Tucson Apple Core, Tucson AZ
Lines: 71

Ivan Cavero Belaunde writes in a message to All

ICB> Disclaimer: I'm heavily biased here, since I *do* believe that 
ICB> OOP is indeed the wave of the future, and I'll try to outline 
ICB> why. 

I agree with you but with slightly different em-faces:

Reusable code as a reason to use OOP? Reusable code has been around for many
years. Libraries that allow the one to use them with only minimal modification?
(a variation of the above and still not THAT significant, convenient, but not
the most important facet of OOP). 

Analysis and Design! 

That is where OOP has a BIG advantage over Structured Programming. If you read
Coad and Yourdin, they make a point that I agree with completely (can you tell
that I am an OOP-freak?):

One can go from a preliminary analysis, to more and more detail, through the
design phase, the algorithm-writing phase, all the way to writing the actual
code, without ever changing one's paradigm--you never have to switch from thinking
in terms of the problem (manipulating objects) to the solution (manipulating
 computer symbols) as the strategy never changes:


Object-Oriented programming             Structured-programming

    Analysis (objects)                    Analysis (objects)
                                           
    Design   (objects)                    Design   (DFD's, flowcharts, etc)
                                           
    Coding   (objects)                    Coding   (traditional sequences,)
               
                                                   (loops, etc)

This makes things much easier for both the programmer/analyst and the customer
to understand. I can describe my work-in-progress in terms that both she and
I use, and any changes that need to be done don't need translation into an arcane
intermediate code like DFD's, etc. Certainly the more complicated the problem,
the more obtuse the programmer's view of things, but it is a natural kind of
complexity, stemming from the programmer's need to have exact knowledge of what
is going on, and not simply a translation from English to computerese. If I
have need for detailed knowledge of the flow of data, of message-passing, etc,
I can still simplify things enough for the customer to understand without deceiving
her (or me) into thinking that we are talking about the same thing when we are
not.
When I tell my client (or she tells me) that whatsis needs to be done with widgets,
x times a day, my preliminary analysis, design, and code all reflect this in
a straight-forward manner, and no matter what level of detail I look at the
program from, from the customer's description, to the final code, I can still
see the same process going on, just in more detail.

Resusability of code and such using OOP is nice, but that's like looking at
one or two trees and missing the fact that you are in the middle of a vast and
wondrous forest.

OOP simplifies analysis, design and coding and makes them just more detailed
aspects of the same thing. That's its most important advantage.


Lawson




 

--  
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org