Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!apple!agate!shelby!neon!pallas
From: pallas@Neon.Stanford.EDU (Joe Pallas)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <1990May25.232337.29009@Neon.Stanford.EDU>
Date: 25 May 90 23:23:37 GMT
References: <1990May20.154035.15064@axion.bt.co.uk> <54783@microsoft.UUCP> <1990May23.061147.22444@tukki.jyu.fi> <1990May23.171152.29448@Neon.Stanford.EDU> <54873@microsoft.UUCP>
Organization: Computer Science Department, Stanford University
Lines: 30

In article <54873@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:

>I'd claim in the following trivial example, the base class *is* broken --
>but you cannot tell that by testing the base class without deriving
>from it.  Conversely, the derived class *is not* broken -- but the 
>bug in the base class only shows up when testing the derived class.
>So I claim that inheritence *does* weaken encapsulation, and you *can*
>break a class by inheriting an implementation from it -- if the base
>class is never derived from, then the present implementation of the
>base class is just fine!  Only in the presence of derivation need the
>base class be fixed.

Does a class change somehow when you inherit from it?  I think not.
So how can the same class be both correct and incorrect?  Only if we
change our correctness criteria.  If the specification of a class says
nothing about inheritance (and, as I mentioned before, no one seems to
have a good way of specifying such things yet), then what happens when
you try to reuse the class cannot determine whether it meets its
specification.

If you make a decision to reuse code THAT MAKES NO PROMISE in its
specification about its reusability, then YOU must take the
responsibility for ascertaining its reusability---you are making a
decision at least as significant as any other implementation decision,
and the correctness of that decision is your responsibility.  If some
otherwise handy class is not reusable, you can go complain to whoever
wrote it, but you cannot blame that person for your decision to reuse
the code inappropriately.

joe