Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!cs.utexas.edu!rutgers!deimos!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.object
Subject: Comments on OOP style
Message-ID: <135300027@p.cs.uiuc.edu>
Date: 5 Feb 90 04:39:00 GMT
Lines: 83
Nf-ID: #N:p.cs.uiuc.edu:135300027:000:4481
Nf-From: p.cs.uiuc.edu!johnson    Feb  4 22:39:00 1990


jimad@microsoft.UUCP said
>[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]

This is completely untrue.  Design encapsulation is important in Smalltalk
just as in any other language.  It is true that there is a different style
that is used in Smalltalk when one is rapid-prototyping than when one is
designing reusable code, but this does not seem to be the topic under
discussion.  Instead jimad@microsoft seems to be claiming that the
Smalltalk philosphy is to ignore maintainance, elegant design, etc.
In fact, I think that good Smalltalk worry about elegant reusable
design more than any other kind of programmers.

>A symptom of this problem in Smalltalk-like languages is having mimimum
>executable sizes of about a half megabyte.
The minimum executable in Smalltalk-80 is actually 50K or smaller.
One of my students was able to make a version of the system tracer
and get it that small.  My guess is that more work could have made it
smaller.

My response really didn't address the point of this complaint, though,
which was that one class really shouldn't access very many other classes.
The statement that one class should never access more than six other
classes is clearly false in Smalltalk, since Number, Boolean, Block,
String, Character, Collection, and Stream are used by most classes, so
imposing a limit of six classes would mean that no new classes could
be used.  

A argument against my point of view might be that these classes
don't count, that they are really part of the language and not part of
the application and thus shouldn't be counted.  Smalltalk is a wierd
language, some would say, because things that are usually built into
the language are implemented by class libraries.

However, Smalltalk programmers not only consider the above mentioned
classes to be "part of the language", they consider the graphics and
the user interface classes to be standard.  If a company has a standard
set of classes then programmers start to treat them as part of the
language, too.  The great thing about OOP is that it makes languages
extensible, and once a class library has become standard then people
don't have to think about it any more.

Whether he knew it or not, jima@microsoft probably suggested six as the
right number of class interfaces in a system because the human short term
memory can only remember 5 to 9 things at a time.  However, classes that
become standard become part of the long term memory, and there is no
limit (or at least a much larger limit) on long term memory.  Thus, once
classes become standard then they shouldn't be counted in the cognitive
size of a system.

This is one of the reasons that Smalltalk seems too complex to beginners
but is so productive to experts.  Beginners have to stuff 20 or 30
things in short term memory before they can understand a program, and
this is nearly impossible.  However, almost all these interfaces are
standard, so from the point of view of an expert there are only two or
three new interfaces in the application and it is quite simple and easy
to understand.

So, I think that the recommendation that no C++ class should access
more than 6 .h files is wrong.  It doesn't matter how many standard
classes are accessed, it is only the non-standard classes that count.  

I would give a similar argument against the requirement to limit the number
of methods in a class to 10-20.  In a standard class, it doesn't really
matter how many methods there are as long as they are easy to understand.
(Carried to extremes, of course, this is not true.)  In a new class, it
is only the interface that needs to be small, i.e. you should have no more
than 10-20 public methods.  However, it doesn't matter how many private
methods you have, as long as they are all easy to understand and useful.

>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.
The problem with this recommendation is that it has nothing to do with
OOP.  Design encapsulation is an extremely important property of good
design, regardless of the programming style.  I agree---place first and
very much foremost design encapsulation as the most important property
of good design of reusable software.  However, I expect that you could
achieve this property in non-OOP languages.

Ralph Johnson