Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!rutgers!princeton!allegra!mit-eddie!genrad!decvax!tektronix!tekgen!orca!tekecs!jeffmc
From: jeffmc@tekecs.UUCP
Newsgroups: comp.lang.misc
Subject: More on OOP
Message-ID: <8049@tekecs.TEK.COM>
Date: Thu, 22-Jan-87 17:53:49 EST
Article-I.D.: tekecs.8049
Posted: Thu Jan 22 17:53:49 1987
Date-Received: Sat, 24-Jan-87 09:47:07 EST
Reply-To: jeffmc@tekecs.UUCP (Jeff McKenna)
Distribution: world
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 49

Some comments:

I consider dynamic (or at least late) binding as an important part of the
power of OOP. The success of reuseable code appears to be contingent
on dynamic binding. See Brad Cox's book for a lucid description. Our
experience with OOP is that reuseable code is possible and, in fact,
probable. Software factories are possible and if we don't do them then
someone else will. Class hierarchies and message passing (the OOP word
for polymorphism) give this power.

A serious problem in S/W for the the real world (people who have
problems that need solving and who are concerned with the useability
of the solution) is that S/W is not useful. It may be fast but it is not
what is needed. OOP appears to put the necessary power in the hands
of the developer to develop what is needed from the customer point of
view. We find folks doing very rapid prototyping using OOP and being
able to quickly try out ideas from designers and customers. When
designs are 'complete' the implementor can worry about specific
performance issues. The rate that hardware performance is increasing is
making performance a non-issue for more and more problems. This is
especially true in the area of human computer interface - humans don't
move that quickly. HCI is also very hard to specify without prototyping.
I am not avocating this approach for all problems but it is very useful
for many problems.

Another serious problem is the question of integration and maintenance.
All of the multiple person OOP projects we have worked on or worked on
with customers have had extremely easy integration. Encapsulation
does it. Maintenance also has proven to be easier since the modification
of one portion of code rarely changes behavior in unexpected ways. The
OOP approach usually makes it very easy to find the location of errors.
I have taken medium sized Smalltalk code that I have never seen before
and then found and fixed bugs in minutes (I mean that - not hours!).

One last comment: There has been discussion here and in other places
about the 'silliness' of using a message passing syntax. Closure works,
or just use functions, or some such. I disagree strongly. B.L Worff has
hypothesized that the language you use directly affects your thought
process. We have found that even within a OOP program the actual
names (selectors) used for the messages can have a strong influence on
the understanding of a piece of code. From the users point of view,
asking something to do something by using a message is very different
from invoking a function. Just think about who is in control. The two
methods may in fact be isomorphic but only in theory, not in practice.
What I really want is the ability to invoke a function when that is the
obvious thing to do and send messages when that is the obvious thing.
But I don't want to do this by cobbling up some strange syntax.

Thanks, Jeff McKenna   (503) 685-2943  jeffmc.tekecs@tektronix.com