Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!csus.edu!ucdavis!csusac!unify!Unify.com!grp
From: grp@Unify.com (Greg Pasquariello)
Newsgroups: comp.object
Subject: Re: How do you evaluate objects?
Message-ID: <1990Nov30.072551@Unify.com>
Date: 30 Nov 90 15:25:50 GMT
References: <23645@grebyn.com> <11379@goofy.Apple.COM>
Sender: news@Unify.Com (news admin)
Reply-To: grp@Unify.com (Greg Pasquariello)
Organization: Unify Corporation, Sacramento, CA, USA
Lines: 58

I just have two comments that may be meaningful.  Then again, they may
not :-)

In article <11379@goofy.Apple.COM>, Piersol@Apple.com (Kurt Piersol) writes:
> 
> I'd suggest some other evaluation criteria, based on experience building 
> scalable systems with Smalltalk-80. Thus, I'll use Smalltalk-80 terms to 
> describe them. These are:
> 
> 1. Abstraction - Where possible, the object should never refer explicitly 
> to any other class. Any dependencies on other objects should be strictly 
> protocol based, to assure as strong an encapsulation as possible. If you 
> do this, as time passes, you'll find that you spend less time on 
> algorithmic details and more on understanding the transformations and 
> movement of your data.
> 

One comment I have about your abstraction criteria, is that it may not be
quite broad enough.  I believe there are two kinds of objects, "dumb" 
objects, and "sentient" objects.  Dumb objects do not know about other
objects, and provide the strong encapsulation.  Sentient objects however,
are aware of other objects (most notably, dumb objects), and know how to 
make use of and interact with them.  Using the example from Ronald Schultz,
the block of wood and the drill are the dumb objects;  they do not know
about each other, and provide highly encapsulated classes.  The person,
on the other hand, is aware of both the drill and the block of wood, and
knows exactly how the two can interact, but provides only a weak encapsulation.
As in life, if a new kind of drill comes along (i.e. drillPress), the
person needs to get new instruction; he needs to be subclassed to 
drillPressOperator, maintaining the knowledge of how to use a drill on
a block of wood, but with the new knowledge of how to use the drill press
to manipulate the drill.

> 2. Parsimony - Not only is it important to have necessary operations 
> visible, but it is important to have only operations appropos to the 
> particular object located there. Although it may be tempting, for 
> instance, to take a specialized transformation and locate its code in the 
> originator of the transformation, it's better to locate it in the 
> recipient. If you need to build a ROT13 transform for your mail reader, 
> put the operation on class String, rather than class MailReader. That way, 
> other programmers can find the capability and make use of it in 
> serendipitous ways.

My only comment here, is based on the last sentence.  Object designers must
be careful to include only operations on the class (as you mention), and
not include gratuitious operations that someone may find serendipitous
later.

> Kurt
> Kurt Piersol                                           Apple Computer ,Inc.
> arpa: Piersol@Apple.com                                  20525 Mariani Ave.
> uucp: ...!apple!piersol                                Cupertino, CA 95014
> ALink: PIERSOL.K                                              408/974-1201
--

---
Greg Pasquariello	
Unify Corporation 	grp@Unify.Com