Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tdatirv!sarima
From: sarima@tdatirv.UUCP (Stanley Friesen)
Newsgroups: comp.lang.c++
Subject: Re: Advice on design
Message-ID: <136@tdatirv.UUCP>
Date: 28 Aug 90 16:01:03 GMT
References: <882@zinn.MV.COM> <129@tdatirv.UUCP> <1197@fang.dsto.oz>
Reply-To: sarima@tdatirv.UUCP (Stanley Friesen)
Organization: Teradata Corp., Irvine
Lines: 22

In article <1197@fang.dsto.oz> dch@aeg.dsto.oz.au (Dave Hanslip) writes:
>sarima@tdatirv.UUCP (Stanley Friesen) writes:
 
>I assume this refers to "Object-Oriented Program Design with Examples in C++"
>by Mark Mullin. I've seen this opinion expressed before. Perhaps you could
>explain why.

	Yes, that's the one I meant.   There are a number of things that
bother me about his approach to C++ programming.  I find that he goes out
of his way to create class hierarchies that neutralize or bypass C++'s
type checking capability.  And he seems to think this is a *good* thing.
In Smalltalk this is appropriate, since that language operates on a purely
polymorphic, essentially typeless model.  In C++ it is like driving without
a seat belt.
	The most obvious example of this in Mullin's book is his insistance
that all container classes be fully polymorphic.  He does this even when the
design clearly limits the type of object that can legitimately be placed in
the container.  This eliminates one source of correctness checking that the
C++ compiler would otherwise be doing for you.  In C++ it is foolish not to
let the compiler help in this way.   Thus a container class for widgets
should only accept widgets, and a containr class for doodads should only take
doodas.  There is no reason to force a doodad container to accept widgets.