Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (JAMES ADCOCK)
Newsgroups: comp.object
Subject: Re: Comments on Object Oriented Programming
Message-ID: <10432@microsoft.UUCP>
Date: 2 Feb 90 22:10:10 GMT
References: <4942@crdgw1.crd.ge.com>
Reply-To: jimad@microsoft.UUCP (JAMES ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 64

In article <4942@crdgw1.crd.ge.com> kornfein@england.crd.ge.com () writes:
X
XWe have used Object Oriented programming here for the last few years and have
Xfound pluses with it but also some minuses.
X ...
XThe difficulties we have had in OO programming mainly occur, using methods, in 
Xthe areas of maintenance and expansion of existing programs. Specifically here
Xare some examples:
X
X1. Inheritance while saving code, has the drawback that it is very hard
X   to follow flow of control of the system this makes tracing bugs often
X   difficult, especially if you didn't write the code to start with.
X
X2. Some of our first OO projects were done by people not very familiar with
X   OO concepts.  The code they produced is almost impossible to
X   decipher.  Our impression is that if not carefully done OO programming 
X   presents greater risks of producing "spaghetti code" than procedural
X   systems.  Dynamic binding of methods can be as misused as assigned goto's.
X ...
XAny comments??

IMHO, after just spending the last couple months looking at these problems
in some very well known Object Oriented code, a major error in what most
people are presently doing is *way too much* emphasis on OOP as a tool for
"code reuse" and "code sharing," and *way too little* emphasis on OOP as
a tool for encapsulating design decisions.  Unfortunately, I don't think
any present OOPL gives us what we really need in terms of strict design
encapsulation.

A common example of this problem is all those code libraries that take
a Smalltalk like approach of having Object depends on Class depends
on ABunchOfContainerClasses depends on TheWholeKnownWorldOfProgramming.
[The Smalltalk philosophy being to "ignore" design encapsulation and
 to give users fast response tools to allow one to keep hacking until the 
 code works]

A symptom of this problem in Smalltalk-like languages is having mimimum
executable sizes of about a half megabyte.

A symptom of this problem in C++ is #including [directly or indirectly]
about 50Kbytes of .h files for each 1K .c file compiled ["How come it
takes me two hours to compile this little draw application?"]

So my recommendation is to place first and very much foremost design
encapsulation as the most important OOP *good* property -- yes, even
much more important than inheritence.

My claim is that the maximum number of other classes a class should depend
on, either through inheriting features, delegation, or just asking an
object of one of those classes to do something is about 6.  In C++ one
could interpret this as saying the max number of include files you should
ever need for a successful compilation is about six [*including* the .h
files that other .h files include]

My claim further is the "right" number of methods an object should support
is closer to 10-20 than 100-200.  Likewise instance variables.

Even with these restrictions, someone reading a given class has the potential
of getting exposed to maybe 100 different class+method functionalities.
I've seen many classes that do much, much worse.

If this sounds like motherhood and apple pie to any readers, I challenge
them to find examples of good "non-trivial" OOP code that meet these 
principles.