Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!lll-lcc!pyramid!voder!apple!lsr
From: lsr@apple.UUCP (Larry Rosenstein)
Newsgroups: comp.lang.misc
Subject: Re: Object-Oriented vs. Abstract Data Types
Message-ID: <393@apple.UUCP>
Date: Tue, 20-Jan-87 21:42:11 EST
Article-I.D.: apple.393
Posted: Tue Jan 20 21:42:11 1987
Date-Received: Wed, 21-Jan-87 21:51:03 EST
References: <4000001@nucsrl.UUCP> <3288@milano.UUCP> <147@m10ux.UUCP> <1023@cuuxb.UUCP> <776@watmum.UUCP>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 71

In article <776@watmum.UUCP> gvcormack@watmum.UUCP (Gordon V. Cormack) writes:
>Object-oriented programming is a religion that is currently in vogue.
>It adds little to the original class ideas of Simula 67, and the
>abstract data type ideas of Clu (which was inspired by Simula 67).
>
>Calling a procedure call a message, and an access procedure a method
>is just arcane.  Really the only thing that Smalltalk and its imitators
>add is dynamic procedure binding and dynamic type checking, which I 
>regard as highly undesirable.
>-- 

The difference comes in how easily you can make changes to your program.
Consider writing a graphics application that deals with shapes (a la
MacDraw).

In Object Pascal (or C++ or Smalltalk) you would define an abstract Shape
class, which defined the interface (protocol) for all kinds of shapes.  In
addition there would be Rectangle, Circle, etc. classes that inherited from Shape.

Your application would manipulate shapes using the methods defined by the
abstract Shape class.  For example, you could create a list of Shape
objects and run down the list drawing each shape.  (In Smalltalk
terminology you would send each Shape object a Draw message.)

It would be very easy to define a new kind of Shape that provides the same
interface and add it to the system; you simply define a new subclass of
Shape.  The graphics application itself would not have to be changed; it
would be able to send messages to the new object type.  

In Clu, you would define a Shape data type (a cluster).  The graphics
application would again deal with Shape objects, without knowing about
their implementation.  To draw all the shapes you would interate through the
list and call Shape$Draw on each shape.

One difference from Object Pascal et al is that you would not define
Rectangle and Circle data types.  If you write code that deals with Shapes,
it cannot also deal with Rectangles.  

(You could not use parameterized modules because they require specifying the
type parameter as a constant.  For example, you could define a List data
type that is parameterized on the type of the data is contains.  You could
not, however, mix different kinds of data in the same list.)

Instead, you would embed in the implementation of Shape, code to handle
each of the kinds of shapes.  Externally, users of Shape would not have to
know whether a particular Shape was a Rectangle or Circle, but the
implementation would.

If you wanted to add a new kind of shape you would have to modify the
implementation of Shape and recompile that module.  The rest of the
application would not have to change.

This is different than the first example, because adding a new kind of
Shape does not require changing the Shape class at all.  The only code that
needs to be compiled is the code that implements the new kind of shape.  It
is not necessary to have the sources to anything else in the system.

The ability to reuse software is not limited to languages that are
interpreted and have no type checking (i.e., Smalltalk).  The same thing can
be achieves with languages such as C++ and Object Pascal that are compiled
and have type checking.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET