Re^2: Integrating concurrent & O-O programming

[oscar@cui.unige.ch (NIERSTRASZ Oscar)]

tma@osc.COM (Tim Atkins) writes:

>In article <7062@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu (Bill Wolfe) writes:
>> ...consider the interference that occurs between class inheritance 
>> and encapsulation when subclasses are allowed to access freely the 
>> instance variables of the parent class [Sny86].  In this case we may 
>> say that support for inheritance diminishes the degree of encapsulation
>> that was achieved without inheritance...

>I have heard this before and, frankly, I don't get it.  The subclass 
>has inherited data structure definition from the parent class.  Therefore
>its instances will contain instances of the parent data structure.  This
>is totally local to the object!  Only the definition was inherited.  Why
>is this a bad thing?  Why does it break encapsulation?  I understood the
>encapsulation wrt data provided by OO techniques to simply state that instance
>data should not be accessed directly but only through a method defined on
>the class.  Therefore, inheritance does not seem to break encapsulation.

>I would appreciate it if someone could set me straight here.

At the level of objects, encapsulation protects the client of an object
from needing to know details of the object's representation.  One simply
"sends messages", i.e., there is a well-defined interface between the
client and the object.  Modifications to the representation should not affect
the client (the service may change somewhat, but the client's code is
still valid).

In object-oriented languages, there are (at least) *two* clients to
object classes: the clients of the object instances, and subclasses
that wish to inherit the code.  If you view inheritance as purely a
machanism for share code and interfaces within a collection of object
classes (i.e., if you are a lone programmer) then there is no reason
why subclasses should not see everything they inherit.  But if you are
implementing a class library for use by other programmers, or if you
wish yourself to make use (reuse) by inheritance of existing classes,
you would like to protect subclasses from modifications made to
superclasses.  That is why some languages permit subclasses to make
use only of instance variables and methods explicitly exported.

What aggravates the situation is that in order to implement useful
subclasses, you often *want* subclass instances to access (hidden)
inherited instance variables and private methods.  This means that either:
1. the implementor of a subclass must completely understand not only
	the source code of the superclass, but also everything inherited
	by the superclass from *its* superclasses etc.
	(deciphering the "yoyo" effect in the presence of self and
	super can be like trying to read a program loaded with gotos)
or:
2. the interface of the superclass to inheriting subclasses must be
	specified as completely as the interface of an object to
	its clients.
We would prefer solution 2, but unfortunately we don't know how to do this
very well, although we try sometimes to make do with natural language.
("If you inherit from this class, make sure you don't modify variable x,
unless you ...")

Finally, when we have "concurrent objects", i.e., objects that make
use of concurrency and synchronization mechanisms in their methods,
subclasses inheriting such code must be careful about how they
extend the superclass behaviour to avoid nasty surprises.

Our experience in designing and implementing a concurrent object-oriented
language ("Hybrid" -- see OOPSLA '87) revealed that concurrency mechanisms
that seem quite reasonable at the object level, can pose difficulties
in the presence of inheritance and composition (e.g., using a concurrent
object as an instance variable can create unexpected results).  Although
the conflict between concurrency mechanisms and object-oriented features
such as inheritance has been noted by many researchers, clean integration
is still an open problem.

Oscar Nierstrasz

---------------------------------------------------------------------
Dr. O.M. Nierstrasz                     E-mail: oscar@cuisun.unige.ch
Centre Universitaire d'Informatique     Tel:    41 (22) 787.65.80
12 rue du Lac, CH-1207 Geneva           Fax:    41 (22) 735.39.05
SWITZERLAND                             Home:   41 (22) 733.95.68
---------------------------------------------------------------------