[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jun 30 13:25:01 1993 
Subject:Re: Opposed views on the nature of OOP diagnosed 
From:Steve Knight 
Volume-ID:930630.08 

Aaron Sloman describes two viewpoints on object-oriented programming:

> A. For people most concerned with *safety* in software design, i.e.
> prevention of unwanted interactions between software developed by
> different people or developed at different times, or who wish to have
> "safe" interfaces between modules concerned with distinct data-types,
> the encapsulation and data-abstraction will be particularly important.
> This goal requires only a slight change to most forms of
> data-structures, to prevent access to datastructures except via
> procedures (methods) defined for those data-structures.

> B. For people most concerned with the *expressive power* of a language,
> i.e. making it possible to design complex software with least effort,
> with reduced duplication of code and minimal errors due to inconsistency
> in how one defines multiple closely related data-types, and maximum ease
> of change if one wishes to make a system more general, the support for
> inheritance and polymorphism are the most important features common to
> object oriented languages (including, for example, Simula67, Smalltalk,
> C++, CLOS, Pop-11 Objectclass, Dylan, Eiffel, etc.)

As far as I can tell, the [A] viewpoint simply has nothing to do with
object-oriented programming.  In order to achieve encapsulation we need
a suitable name-hiding mechanism.  In order to achieve data abstraction
we need to able able to invent new, distinct types.  Neither of these
requirements have any involvement with OOPS except ``by coincidence''.

When a class-like feature is grafted onto a programming language (and 
I am thinking of C++ in particular) it is an opportunity to remedy other
language issues.  In the case of C++, we have a language with very poor
name-space control and very limited type creation.  When classes were
added to C to create C++, a new and complicated name-space control
mechanism was added along with an ability to conveniently create new
types.

In languages such as POP-11, there are already adequate name-space
control features and the ability to freely create new types.  As a 
consequence, POP-11 already provides good encapsulation and 
abstraction facilities.  So when a designer (such as myself) invents 
an object-oriented extension, it is inevitable that they pursue the
philosophy outlined as [B] above.  It would be pointless to pursue [A].

One good example of philosophy [A] is provided by Ada.  Ada has no
object-oriented facilities.  However, it does provide good name space
control facilities and a good way of creating new, distinct types.  As
a consequence, data encapulation and abstraction are well-supported.
There are even courses in ``object-oriented design'' in Ada.  But to
suggest that Ada is an object-oriented language would be futile.  

Steve

PS.  I think the argument gets heated simply because the terms being used
aren't well-defined.  So here is the definition of terms that I have
used in this note:

Object-oriented:
  I understand object-oriented to be rather vague
term but, for me, at its core is the idea that the *same* procedure 
can be applied to *different* types to achieve a single effect.  In
OOPS jargon procedures get called methods and types get called classes but
I regard that uninteresting.  

Data encapsulation & abstraction:
  The term "data encapsulation" refers to the
idea that no ``superfluous'' variables are visible outside the definition
of a new data types.  And the term "data abstraction" refers to the ability
to create genuinely new types from old types.