Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!elephant.cis.ohio-state.edu!weide
From: weide@elephant.cis.ohio-state.edu (Bruce Weide)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Message-ID: <88851@tut.cis.ohio-state.edu>
Date: 25 Feb 91 16:59:22 GMT
References: <88431@tut.cis.ohio-state.edu> <6108@stpstn.UUCP> <87829@tut.cis.ohio-state.edu> <6248@stpstn.UUCP> <1991Feb11.103100.112@skyler.mavd.honeywell.com> <34464@athertn.Atherton.COM> <88744@tut.cis.ohio-state.edu> <jls.667345738@yoda>
Sender: news@tut.cis.ohio-state.edu
Reply-To: Bruce Weide <weide@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 38

In article <jls.667345738@yoda> jls@yoda.Rational.COM (Jim Showalter)
asks why code inheritance is problematical for verification, etc., and
why I called it an "inherently white-box" phenomenon.

Briefly, what I mean by code inheritance is a situation in which an
heir may directly manipulate the internal representational details of
its ancestor(s).  That is, unlike an ordinary client of a component --
which must rely on an abstract description of the component's behavior
and may use only the interface operations/methods in order to
manipulate it -- an heir using code inheritance may see and directly
manipulate the ancestor's internal representational details, bypassing
the interface operations/methods.  If an heir is not permitted to
violate abstraction like this, what is the use of code inheritance?
The heir might as well be an ordinary client.

The difficulties with verification, testing, etc., arise because of
implementation "conventions" that were used by the ancestor's
implementor, but which are not stated explicitly in the code itself
(because most languages don't have any constructs in which to express
them).  The problems arise even when the heir is permitted only to
manipulate the current internal representation of its ancestor.  It is
not necessary that the heir be able to add "representation features"
(or whatever you want to call them) in order for these problems to
occur.

For example, the implementor of the ancestor might be relying on some
particular relation (a representation invariant) holding at all times.
If an heir comes along and manipulates the representation in such a
way that this invariant is violated then the ancestor's operations may
be broken.  No one has touched the code of the ancestor, but they need
to be reverified, retested, whatever.  This is a disaster.

For a specific example and more information, you might see papers in
Proceedings 8th Annual National Conference on Ada Technology, 1990,
pp. 515-524; and in Journal of Object-Oriented Programming, Jan-Feb
1990, pp. 13-19.

	-Bruce


Brought to you by Super Global Mega Corp .com