Re: Integrating concurrent & O-O programming

[dlw@odi.com (Dan Weinreb)]

In article <1667@osc.COM> 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. 

There is definitely a degree of truth in what Wolfe says.  To get down
to brass tacks, the problem arises if I write a base class B, and you
make from it a derived class D.  (In other jargon, D inherits from B.)
Your function members (methods) on D freely use the data members
(instance variables) in B.  Fine.  Time passes.  I now go back and
modify B, either to add new features or improve performance.  In so
doing, I change the internal guts of the implementation of B, which
are supposedly hidden by virtue of encapsulation.  This is OK for
outside "users" of B.  However, D has "inside information": it knows
about the raw internal guts of B, namely the data members (instance
variables).  So my changes to B, which are supposed to be invisible
and hidden by the encapsulation, break D.

Smalltalk-80 really has this problem, and there is no language
mechanism in Smalltalk-80 that deals with this.  (I was told this
by one of the great Smalltalk-80 experts.)

C++ provides a feature specifically intended to address this
phenomenon, namely "protected", which allows the writer of B to
specifically distinguish between those data members that are hidden to
writers of derived classes, and those that are visible.  This seems to
me like a promising approach.  Only many years of experience with many
megalines of code will tell us all how well this works.  Perhaps there
are other languages out there in widespread use that try to deal with
this problem.

Dan Weinreb		Object Design, Inc.		dlw@odi.com