Re: OO Idiom: Interfaces for derived classes

[ncohen@watson.ibm.com (Norman H. Cohen)]

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