Path: utzoo!attcan!uunet!cs.utexas.edu!wuarchive!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.object
Subject: Re: Integrating concurrent & O-O progra
Message-ID: <135300018@p.cs.uiuc.edu>
Date: 25 Nov 89 17:38:40 GMT
References: <7062@hubcap.clemson.edu>
Lines: 32
Nf-ID: #R:hubcap.clemson.edu:7062:p.cs.uiuc.edu:135300018:000:1776
Nf-From: p.cs.uiuc.edu!johnson    Nov 24 10:08:00 1989


Tim Atkins comments on the claim that inheritance violates encapsulation
and says that he doesn't believe it.

Brian Gilstrap responds:
>Class A inherits from class X.  In many OO programming languages if not
>most that means that A gets to access X's local data items.  Thus, if X
>had a data item 'foo', code from class A could directly access 'foo'.
>This means that class doesn't just depend upon the interface of X but
>also depends upon the implementation of X.  This means that if X changes,
>A may have to change (and anything which is a descendant of X including
>all of A's descendants).  This tends to make those classes near the root
>of an inheritance heirarchy become "rigid" very quickly, since changes
>can "ripple" down the heirarchy.  This is viewed as a bad thing since the
>whole point of OO is to avoid "ripples" which propagate through a software
>system.

Although this is technically correct, I don't think it has much practical
effect.  The major problem in C++ is that one often needs to change the
return types or argument types of classes, or one needs to add a new
function to a class.  This is changing the interface.

The interface that a class presents to a subclass is much broader than that
which it presents to a client.  I am a strong believer in abstract classes,
which depend on their subclasses to make a number of key design decisions.
Abstract classes don't usually have many instance variables, so changing them
is not a big problem.  Most interesting changes to an abstract class are really
changes to the interface.  If it were possible to hide lots of information
in a class, then that class probably should have been reused as a component
rather than as a superclass.

Ralph Johnson -- University of Illinois at Urbana-Champaign