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 dominant 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
EMAIL A.Sloman@cs.bham.ac.uk OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711 Fax: +44-(0)21-414-4281
|