Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!bu.edu!att!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: Inheritance and Information Hiding
Summary: On being chummy with your descendants
Message-ID: <477@mole-end.UUCP>
Date: 3 Feb 91 07:12:01 GMT
References: <1991Jan23.224203.3206@runx.oz.au> <1991Jan24.214652.18515@Think.COM> <1991Jan29.221121.20642@odin.corp.sgi.com>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 35

> |> >In practice, I've found C++ `private's to be overly restrictive and in
> |> >violation of the rule "it is not the buisiness for a class to decide how
> |> >it may be extended in the future" (paraphrased from OOSC).

> |> >It's another example of a C++ feature that actually reduces the
> |> >reusability of C++ classes ....

> Private is for things that might change.  If you make them protected and
> then change them, you break subclasses.  So if you're not willing to commit
> to keeping something around, then you should make it private.  ...  I now
> believe the appropriate default is private.  If I make something available
> to a subclass, I should think carefully about what I am giving out.

How chummy you should be with your DERIVED CLASSES (`subclass' is a word that
belongs to another language and to certain theories of programming) depends,
I think, on what your relationship to them is.  If, as an engineering reality,
the base class and its derived classes are written and maintained as a unit,
and if the inheritance expresses a cuddling-close relationship, then there's
no reason why the data layout and data-layout dependencies shouldn't be
visible to the derived classes.

In other cases, it's probably a poor idea.  Note, *PROBABLY*.  Where the
base class's data layout is a matter of record (perhaps it maps some
data layout that is externally imposed, or that is essentially immutable in
the face of the algorithms/mechanisms which the code is DEFINED to implement)
it might make sense to make the data layout a part of the class's interface.

We have to remember that we are solving problems.  Such things as indentation
and brace layout can be argued about without taking the problem into account.
The same cannot always be said about how the parts of the program are willing
to relate to each other.
-- 

 (This man's opinions are his own.)
 From mole-end				Mark Terribile