From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9eccdbc9cfa1c9b9
X-Google-Attributes: gid103376,public
From: ncohen@watson.ibm.com (Norman H. Cohen)
Subject: Re: OO Idiom: Interfaces for derived classes
Date: 1996/03/22
Message-ID: <4iumd6$113p@watnews1.watson.ibm.com>#1/1
X-Deja-AN: 143724991
distribution: world
references: <199603220939.KAA00777@email.enst.fr>
organization: IBM T.J. Watson Research Center
reply-to: ncohen@watson.ibm.com
newsgroups: comp.lang.ada
Date: 1996-03-22T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <199603220939.KAA00777@email.enst.fr>, Jean-Pierre Rosen
<rosen@EMAIL.ENST.FR> writes: 

|> There are two views of derived classes. Suppose you are the provider of some
|> reusable software components, and you want to provide guarantee on your product.
|>
|> 1) The product as a whole is a hierarchy of classes (for example, a set of
|> widgets).  For design as well as for efficiency reasons, it makes sense to
|> have derived classes defined in child packages, and since it is YOUR
|> product, you don't mind derived classes accessing the parent's private part.
...
|>
|> 2) The product is a set of classes, that are INTENDED to be extended by the
|> user. The user should not do this in child packages, because you cannot
|> guarantee your product if the *user* accesses the private part of the
|> parent. Actually, the  guarantee would have a clause "guarantee is void if
|> classes are derived in child packages", similar to a TV set with a clause
|> "guarantee is void if the user opens the back pannel".

Yes, this is a very useful distinction.

--
Norman H. Cohen    ncohen@watson.ibm.com