Xref: utzoo comp.object:2460 comp.lang.c++:11366
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!dog.ee.lbl.gov!pasteur!galileo.berkeley.edu!jbuck
From: jbuck@galileo.berkeley.edu (Joe Buck)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Inheritance and Information Hiding
Message-ID: <10608@pasteur.Berkeley.EDU>
Date: 30 Jan 91 18:29:04 GMT
References: <1991Jan23.224203.3206@runx.oz.au> <1991Jan24.214652.18515@Think.COM> <TYNOR.91Jan25110611@hydra.gatech.edu> <27A44871.5586@tct.uucp>
Sender: news@pasteur.Berkeley.EDU
Reply-To: jbuck@galileo.berkeley.edu (Joe Buck)
Lines: 99


According to tynor@hydra.gatech.edu (Steve Tynor):
> >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).

In article <27A44871.5586@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes:
> An interesting "rule" -- one with which I happen to disagree.

I also disagree.  There is a tension between information hiding and
inheritance, and both are valuable concepts.

The ability to reuse code is very valuable, but the ability to
separate interface and implementation, and to be able to, in many
cases, redesign the implementation without affecting the user of
a class is extremely valuable.

But what the advocates of never using "private" are forgetting is
that the person that derives from a class is also a user of the
class -- one that is more privileged than the average client, but
a client nevertheless.

Chip goes on to write:
> In any case, language features don't stand up and say, "Use me!"  Who
> can say that there will never be good reason to make members private?
> Not I -- even though I use "protected" five times more often than I
> use "private".

"private" is very valuable for enforcing invariants: for example, assuring
that certain data members will always have a certain relationship.  For
example, consider a class of objects that represent two-way connections.
The base class has only one data member: a pointer to the object that is
connected to it (a null pointer will represent no connection).  We want
derived classes to be able to manipulate the connection however they please,
with this proviso: if A is connected to B, B is connected to A.  If A
is deleted, B will revert to being disconnected (we will never have
a dangling pointer to a deleted object).

Now, suppose we want derived classes to be able to control the type of
object that is connected to it: a DerivedConnection can only be connected
to another DerivedConnection.  This means we don't want the raw connect
methods to be generally accessible: we make the methods protected, so
derived classes can build on them however they like.

Here is a subset of the interface:

class Connection {
private:
	Connection * peer;		// who I am connected to
protected:
	// disconnect me if I am connected
	void disconnect() {	
		if (peer) peer->peer = 0;
		peer = 0;
	}
	// form a new connection
	void connect(Connection& newPeer) { 
		disconnect();
		newPeer.disconnect();
		peer = &newPeer;
		newPeer.peer = this;
	}
	// return who I am connected to
	Connection * myPeer() const { return peer;}
public:
	Connection() : peer(0) {}
	~Connection() { disconnect();}
}

A real implementation will have additional functions; myPeer might be
public.

> >It's another example of a C++ feature that actually reduces the reusability
> >of C++ classes (non-virtual member functions being the other obvious one).

Reusability is not the only thing we care about.  Those of us building
large systems also care about robustness.  Notice that the above code
(modulo any bugs or stupidity; I haven't checked it) enforces several
assertions about connections that I can count on: these assertions can't
be broken by derived classes OR by clients.  Only two methods can alter
a "peer" pointer.

> Virtual functions are available when appropriate; but I'm just as glad
> that I need not pay the performance penalty when I don't need them.

Agreed.  Imagine the performance drag if every function in a complex
number class were virtual.

C++ is not Smalltalk, and object-oriented programming is not Smalltalk
programming.  Ready Grady Booch's book for a lot more detail on the
private/protected/public distinction.

|> Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
|>        "If Usenet exists, then what is its mailing address?"  -- me
|>              "c/o The Daily Planet, Metropolis."  -- Jeff Daiell

--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck