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