Re: Integrating concurrent & O-O programming

[anders@cui.unige.ch (BJORNERSTEDT Anders)]

In article <1667@osc.COM> tma@osc.UUCP (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?  

It does break encapsulation. 
Whether or not this is desirable is another matter. 
If you make the distinction between specification and implementation
of classes and considder inheritance of specifications as the
primary thing then you do want encapsulation. But if inheritance of
implementation (including representation) is the primary thing then you 
dont want encapsulation. Note: You may have both inherritance of specification
and inheritance of implementation at the same time, in fact this is what you
get by default in nearly all existing oo-languages. The question then becomes
what you want to emphasize: the inheritance of an abstract datatype or the 
inheritance of a concrete datatype ?

The programmer implementing a supertype may not be the same person as
the programmer implementing the subtype and may not want implementors
of subtypes to build in dependencies on, or make assumptions about, the
internal representation of the supertype (same arguments as always
for encapsulation). 

Thus, yes the instance contains "instances" of the parent structure,
and yes this is totally local to the object, but you may still want
encapsulation (or partitioning) internally in the object. 

If inheritance of specification is the emphasis you may still have
default inheritance of implementation. This just means that the implementor
of the subtype is liberated of the job of providing the implementation
for the supertypes. It does not mean that the implementor of the subtype
can "poke arround" in the implementation of the supertype.

Anders
---------------------------------------------------------------------
Anders Bjornerstedt			E-mail: anders@cuisun.unige.ch
Centre Universitaire d'Informatique             
12 rue du Lac, CH-1207 Geneva
---------------------------------------------------------------------
Tel:    41 (22) 787.65.80-87             Fax:    41 (22) 735.39.05
Home:   41 (22) 735.00.03                Telex:  423 801 UNI CH
---------------------------------------------------------------------