Opposed views on the nature of OOP diagnosed 
Author Message
 Opposed views on the nature of OOP diagnosed

As is well known to many readers of these news groups, different views
as to the "essence" of object orientation abound, and they are often
held with the strength of religious dogmas.

After a particularly intense debate a little while ago, I reached a
hypothesis regarding at least two of the sub-cultures, and thought it
might be worth sharing.

I have often noticed that one group of people (A) regard encapsulation
(data-hiding) and data-abstraction as the main feature of object
orientation, and others (B) have tended to regard the use of inheritance
(and the associated polymorphism of methods) as the main feature.

[There are other contrasts in views which I'll ignore for now.]

I now think I understand the source of at least this divergence of
viewpoint regarding OOP.

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.)

Because I tended to fall into category (B) I have several times been
very surprised to find people defining OOP without even mentioning, or
emphasising inheritance hierarchies, especially as I have used languages
that satisfy the needs of (A) but were never called object oriented.
(One can satisfy the requirements for (A) simply by using very
disciplined programming practices in any language with support for
user-defined data-types.)

Similarly people who are in category (A) regard inheritance as being of
secondary importance compared with abstraction and encapsulation, and
were therefore surprised at my surprise!

There have been similar strong divergences between the two views as to
what's important about OOP in discussions on Usenet, e.g. in
comp.lang.dylan (where (B) seems to be the {*filter*} viewpoint of the
designers, so that those with viewpoint (A) are critical of some of the
design decisions) and also in the comp.object newsgroup where the
divergence is not related to a particular language, but to OOP in
general.

Clearly both (A) and (B) make important points, and neither is right or
wrong.

It would be interesting to speculate on the reasons why there are these
two views. I suspect there's a mixture of reasons, including

--- which OO language people first used (e.g. some people who started
    with Smalltalk are strongly atteached to "message sending" syntax,
    and strongly opposed to multi-methods and treating method invocation
    as simply a special case of procedure invocation),

--- whether they were first taught about OOP by a dogmatic teacher (lots
    of teachers of computer science / software engineering are very
    dogmatic about their own viewpoints!)

I suspect that a deeper reason for tending to viewpoint (A) or (B) has
to do with which kinds of software development problems people have
previously worked on, and what difficulties they experienced. People who
have worked on large projects where unwanted interactions between
data-structures have caused run-time bugs want the language to *enforce
a stronger discipline*. (e.g. data-hiding.)

People who have worked on large projects where complexity and
duplication of code led to problems of design and maintenance want the
language to *provide greater expressive power*.

(I don't know where people who have never worked on large software
projects get their preferences from!!)

I suspect this is a special case of a more general conflict of views
between those who want languages to be restrictive in ways that
eliminate mistakes at compile time (e.g. Pascal), and those who prefer
languages to be highly expressive so that very difficult problems are
solved with simpler code (e.g. AI languages).

The OOP dispute reminds me very much of the dispute between people who
want *expressions* to be strongly typed so that a lot of checking can be
done at compile time to rule out errors (as in Pascal, ML, C++, Haskell,
etc.) and people who only want *objects* to be typed so that they can
write more general programs more easily, the price being run-time
type-checking (e.g. Lisp, Scheme, Prolog, Pop-11, all of which, for
example, make it easy to write procedures that operate on lists of
objects containing mixtures of types, e.g. a single list containing
words, strings, integers, floats, vectors, arrays, procedures and other
lists).

Again, I think it's clear that neither side is right and there are
good reasons for providing both sorts of languages for different
purposes.

I suspect there's an interesting project to be done by a psychologist, a
sociologist and a computer scientist (or two computer scientists!) to
investigate how these different viewpoints concerning programming
languages develop and why they sometimes polarise people so much.
--
Aaron Sloman,
School of Computer Science, The University of Birmingham, B15 2TT, England

Phone: +44-(0)21-414-3711       Fax:   +44-(0)21-414-4281



Thu, 07 Dec 1995 05:48:12 GMT  
 Opposed views on the nature of OOP diagnosed
Aaron:
  I found your post to be interesting...causing me to reflect on my own
  position.  The results of such pondering are:

  I believe that I come from a position of wanting to minimize the number
  of defects in my software systems.

  This being th' case, it would seem t' me that abstraction and data
  hiding contribute more directly to minimizing defects than does the
  use of inheritance.  However, I am open...and interested, in dis-
  cussions to th' contrary.

                                ...David

================================================================================
David LaGrone               | All comments, opinions and inquiries are my own.
Texas Instruments           | They are NOT to be attributed to Texas Instru-
P. O. Box 650311 M/S 3928   | ments, Inc., or any other employees or agents.
Dallas, Texas 75065-0311    |
(214) 917-1908 fax 917-7519 | Does this satisfactorily exclude everyone but me?
----------------------------+

================================================================================



Sun, 10 Dec 1995 22:33:37 GMT  
 Opposed views on the nature of OOP diagnosed
Aaron:
  I think your post is interesting.  However, my perspective, I believe,
  focusses on what minimizes defects in the software systems I build.
  To THAT end, I believe that data abstraction and data encapsulation
  has more to offer than inheritance and polymorphism.

                                ...David

================================================================================
David LaGrone               | All comments, opinions and inquiries are my own.
Texas Instruments           | They are NOT to be attributed to Texas Instru-
P. O. Box 650311 M/S 3928   | ments, Inc., or any other employees or agents.
Dallas, Texas 75065-0311    |
(214) 917-1908 fax 917-7519 | Does this satisfactorily exclude everyone but me?
----------------------------+

================================================================================



Mon, 11 Dec 1995 02:59:34 GMT  
 Opposed views on the nature of OOP diagnosed

Quote:

>Aaron:
>  I found your post to be interesting...causing me to reflect on my own
>  position.  The results of such pondering are:
>  I believe that I come from a position of wanting to minimize the number
>  of defects in my software systems.
>  This being th' case, it would seem t' me that abstraction and data
>  hiding contribute more directly to minimizing defects than does the
>  use of inheritance.  However, I am open...and interested, in dis-
>  cussions to th' contrary.

  My apologies!  I was unaware that this post got posted!  I lost contact
  with the computer on this end while posting.  Again, my apologies.

                                ...David

================================================================================
David LaGrone               | All comments, opinions and inquiries are my own.
Texas Instruments           | They are NOT to be attributed to Texas Instru-
P. O. Box 650311 M/S 3928   | ments, Inc., or any other employees or agents.
Dallas, Texas 75065-0311    |
(214) 917-1908 fax 917-7519 | Does this satisfactorily exclude everyone but me?
----------------------------+

================================================================================



Mon, 11 Dec 1995 03:03:01 GMT  
 Opposed views on the nature of OOP diagnosed

 ...

Quote:
>   I believe that I come from a position of wanting to minimize the number
>   of defects in my software systems.
>   This being th' case, it would seem t' me that abstraction and data
>   hiding contribute more directly to minimizing defects than does the
>   use of inheritance.  However, I am open...and interested, in dis-
>   cussions to th' contrary.

What happens when inheritance is used to support the use of abstraction?

Consider a program that is well-organized as a set of cooperating
abstractions.  These abstractions have a client-server relationship: one
abstraction provides the vocabulary or the algorithmic structure for
another.  The `problem' is successively re-expressed in terms that get
closer and closer to the machine, with the abstractions and their
client-server relationships forming a DAG.

There are several ways for an abstraction to offer its `services' to
another.  These include function calls, objects to be used, types to
be instantiated, generics to be instantiated, _and types from which
to inherit._
--
 (This man's opinions are his own.)
 From mole-end                          Mark Terribile




Tue, 12 Dec 1995 02:36:30 GMT  
 Opposed views on the nature of OOP diagnosed

   I have often noticed that one group of people (A) regard encapsulation
   (data-hiding) and data-abstraction as the main feature of object
   orientation, and others (B) have tended to regard the use of inheritance
   (and the associated polymorphism of methods) as the main feature.

   A. For people most concerned with *safety* in software design

   B. For people most concerned with the *expressive power* of a language,

[. . .]

   Similarly people who are in category (A) regard inheritance as being of
   secondary importance compared with abstraction and encapsulation, and
   were therefore surprised at my surprise!

In fact, in an earlier discussion in comp.lang.dylan I believe that
some type A people depricated inheritance (especially in presence of
method combination and multi-methods) because you couldn't easily

BEFORE and AFTER methods could be lurking anywhere.



Wed, 13 Dec 1995 03:06:11 GMT  
 Opposed views on the nature of OOP diagnosed
I found nothing on this in the FAQ, so I'm putting it out to the net...

We're starting a project in Allegro CL\PC since Smalltalk doesn't
give us the flexibility we need.  I couldn't find anything in the
documentation or elsewhere about a neat way to organize classes
like the Class Hierarchy Browser does in Smalltalk.  Is there anything
out there that can do the job?

Jim



Tue, 12 Dec 1995 08:25:07 GMT  
 Opposed views on the nature of OOP diagnosed
   NELSON> Nntp-Posting-Host: spot.colorado.edu

   NELSON> I found nothing on this in the FAQ, so I'm putting it out
   NELSON> to the net...

   NELSON> We're starting a project in Allegro CL\PC since Smalltalk
   NELSON> doesn't give us the flexibility we need.  I couldn't find
   NELSON> anything in the documentation or elsewhere about a neat way
   NELSON> to organize classes like the Class Hierarchy Browser does
   NELSON> in Smalltalk.  Is there anything out there that can do the
   NELSON> job?

   I can't speak from experience how well Smalltalk does the job, but
If you use their graphical browser by calling
(inspect (find-class 'class-in-question))

you can rather easily navigate the class meta-object inheritance tree.
I'm not a CL\PC expert, so maybe I'm not aware of a tool for showing a
graphical hierarchy, but I usually find that simple (inspect)
navigation of meta-objects tells me what I need to know.  They do have
a reasonably full implementation of the AMOP MOP.

   I hope that helps.

-Eric

--
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Eric L. Peterson
The MITRE Corporation
7525 Colshire Dr.
McLean VA 22102-3481


Phone:  (703) 883-6116
Fax:  (703) 883-6435

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

                  "I never meta-class I didn't like"

                                -anon

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;



Wed, 13 Dec 1995 22:17:11 GMT  
 Opposed views on the nature of OOP diagnosed

Quote:

>What happens when inheritance is used to support the use of abstraction?
>Consider a program that is well-organized as a set of cooperating
>abstractions.  These abstractions have a client-server relationship: one
>abstraction provides the vocabulary or the algorithmic structure for
>another.  The `problem' is successively re-expressed in terms that get
>closer and closer to the machine, with the abstractions and their
>client-server relationships forming a DAG.
>There are several ways for an abstraction to offer its `services' to
>another.  These include function calls, objects to be used, types to
>be instantiated, generics to be instantiated, _and types from which
>to inherit._
>--

  I don't discount that inheritance makes a contribution to this; however,
  my point is that I don't believe that I get as much lift from inheri-
  tance as I do from abstraction...and I believe that I can build my
  abstraction without inheritance.  (NOT that I necessarily WOULD!  But,
  I could.)

                                ...David

================================================================================
David LaGrone               | All comments, opinions and inquiries are my own.
Texas Instruments           | They are NOT to be attributed to Texas Instru-
P. O. Box 650311 M/S 3928   | ments, Inc., or any other employees or agents.
Dallas, Texas 75065-0311    |
(214) 917-1908 fax 917-7519 | Does this satisfactorily exclude everyone but me?
----------------------------+

================================================================================



Sat, 16 Dec 1995 02:15:22 GMT  
 Opposed views on the nature of OOP diagnosed

Quote:

> Organization: Texas Instruments Incorporated, DSEG HRD Computer Systems Training
> Date: Mon, 28 Jun 1993 18:15:22 GMT
> ....
>   I don't discount that inheritance makes a contribution to this; however,
>   my point is that I don't believe that I get as much lift from inheri-
>   tance as I do from abstraction...and I believe that I can build my
>   abstraction without inheritance.  (NOT that I necessarily WOULD!  But,
>   I could.)

And you don't need an OOP language to give you support for
abstraction. It's a requirement for *any* well structured language
providing user-defined datatypes. (E.g. ML ?)

Good support for inheritance (especially multiple inheritance
combined with multi-methods) is much harder to provide: the main
*lift* it provides is re-usability of the same code for different
data-types. Without proper support for inheritance, it's hard, for
example, to make a single change to the structure or behaviour of a
high level class knowing that the corresponding changes will be made
automatically to all the descendants. So you have to propagate the
changes by hand, i.e. re-writing all the special cases. That's a
recipe for error and inconsistency.

A nice example is provided by the paragraph formats in FrameMaker:
they allow you to do a certain amount of abstraction (i.e. define
your own special paragrph formats). But because they lack
inheritance it is a *real pain* to do certain sorts of style
changes: several different format definitions may have to be
changed separately by hand. If a proper inheritance mechanism were
provided one high level change would suffice (e.g. changing from
Times to Helvetica for a group of related paragraph formats.)

Aaron

Aaron
--
Aaron Sloman,
School of Computer Science, The University of Birmingham, B15 2TT, England

Phone: +44-(0)21-414-3711       Fax:   +44-(0)21-414-4281



Sat, 16 Dec 1995 08:36:58 GMT  
 Opposed views on the nature of OOP diagnosed

Quote:

>And you don't need an OOP language to give you support for
>abstraction. It's a requirement for *any* well structured language
>providing user-defined datatypes. (E.g. ML ?)

THANKS, Aaron!
  I finally saw the light after my last message.  <grin>  You are right!
  And I understand why you are right.  And I agree with you...now that I
  understand.

  Thanks, again, for your willingness to explain this to me in detail.

                                ...David

================================================================================
David LaGrone               | All comments, opinions and inquiries are my own.
Texas Instruments           | They are NOT to be attributed to Texas Instru-
P. O. Box 650311 M/S 3928   | ments, Inc., or any other employees or agents.
Dallas, Texas 75065-0311    |
(214) 917-1908 fax 917-7519 | Does this satisfactorily exclude everyone but me?
----------------------------+

================================================================================



Sun, 17 Dec 1995 02:51:48 GMT  
 Opposed views on the nature of OOP diagnosed

Quote:

>As is well known to many readers of these news groups, different views
>as to the "essence" of object orientation abound, and they are often
>held with the strength of religious dogmas.

> [...]

>I have often noticed that one group of people (A) regard encapsulation
>(data-hiding) and data-abstraction as the main feature of object
>orientation, and others (B) have tended to regard the use of inheritance
>(and the associated polymorphism of methods) as the main feature.

>  [...]

>A. For people most concerned with *safety* in software design, i.e.
>prevention of unwanted interactions between software developed by
> ...

>B. For people most concerned with the *expressive power* of a language,
>i.e. making it possible to design complex software with least effort,
> ...

I have been talking to a close friend, who works for a NASA software
contractor about this for some time now.  He has talked to a lot of
people at JSC about the same issue.  Here is what he told me his contacts
have decided - that there are two philosophies at work:

1) Object _Based_

2) Object _Oriented_

In order to understand the distinction, you first have to understand what
Object Based means.  Object Based means that you _use_ various OO techniques
or even the OO "paradigm" (whatever that is :) in software development.  
This would loosely correlate with A above.  Your development is _not_
object oriented, because the "object" in question is code.

Object Oriented means that there is some real world object, concrete, with
observable behavior and attributes, that your code reflects.  The fact that
you use certain OO techniques is a consequence of the fact that the concrete
object has behaviors that are reflected in the methods of your code "object."
Has properties that are reflected in the attributes of your code "object."
And is related to other objects in a manner that is reflected in the
inheritance hierarchy of your code "object."  Now the line gets fuzzy when
your real world object is something like a user interface, or a database,
which in themselves are objects constructed of code, and are thus abstract.
(a database, however, might very well represent a collection of real objects)

The professor who teaches the OOP courses here (using C++) made the statement
that it should really be called "Class Oriented Programming."  That to me
is a clear evidence that what he is talking about is not Object Oriented
Programming, but rather Object Based Programming.

Another example is a discussion I had with George Stephanopholous (ChE Dept
at MIT).  He went into a discussion about the difficulties of making an
object out of the Newton Rhapson Method.  What popped into my mind at the
time was: "Object?....Um...Er...Uh...I thought it was a _Method_."  Again
clear evidence of Object Based Programming.

Not that Object Based Programming is somehow inferior to Object Oriented
Programming, but it is _not_ the same thing.

As far as why I am interested in OOP, (and I want to understand both
Object Oriented and Object Based), is that I believe that certain problems
that have been unsolvable by traditional methods can be solved.  

James P. Henley Jr.
Department of Chemical Engineering
Auburn University



Sun, 17 Dec 1995 01:35:02 GMT  
 Opposed views on the nature of OOP diagnosed

To put in my two pennyworth on the interchange between Aaron Sloman
and David LaGrone:

Quote:
>> And you don't need an OOP language to give you support for
>> abstraction. It's a requirement for *any* well structured language
>> providing user-defined datatypes. (E.g. ML ?)
>THANKS, Aaron!
>  I finally saw the light after my last message.  <grin>  You are right!
>    And I understand why you are right.  And I agree with you...now that I
>      understand.

Actually, those of us who follow Landin in looking to found computation on
Church's lambda calculus would observe that Church got it right in the
beginning. What you need for well structured computation is:

(a) function application - to do your arithmetic etc.
(b) abstraction, and that is ***lambda-abstraction*** to ensapsulate some
piece of computation.

The elaborations of this basic framework present in actual programming
languages arise from various reasons, many of them BAD.

(A) An implementation of the lambda calculus requires that free variables
be treated properly. Most "real" programming languages don't handle free
variables properly, and have to invent unnecessary constructs (like modules,
packages) to cover the gap. I am as guilty as anybody - having got a tolerable
treatment of free variables in POP-2, we had to go and add sections to the
language, despite their not   being logically necessary. (However efficiency
demands that free variables be implemented in a variety of ways depending
on their context).

(B) Some measure of syntactic sugar on top of the lambda calculus is
desirable, since it is a logicians language, and logicians are concerned with
what is in principle provable, rather than with actually proving things or
specifying algorithms. (Lispers are free to disagree, but I believe that man's
eye was not meant for counting brackets, no nor woman's neither). And we
really would none of us be happy expressing our recursions with the Y
combinator.

(C) Static typing does require a conceptual structure to be built on top
of the lambda calculus, and this impacts the treatment of abstraction.

Robin Popplestone.



Sun, 17 Dec 1995 18:43:09 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Opposed views on the nature of OOP diagnosed

2. Itcled: A few Itcl classes for a OOP view when building a GUI

3. OOP and classes, Was: OOP & Functional Languages

4. OOP Methodology and OOP Tools

5. Diagnose OPCODE X'83'

6. Diagnose-instruction

7. Diagnose A8

8. DIAGNOSE

9. Help file for the CMS Diagnose functions

10. Manuals for new CP Diagnose functions and CMS Maclibs

11. unexplainable behaviour - f90 - looking for some tools to help diagnose

12. Diagnosing a function

 

 
Powered by phpBB® Forum Software