Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!Apple.com!Piersol
From: Piersol@Apple.com (Kurt Piersol)
Newsgroups: comp.object
Subject: Re: How do you evaluate objects?
Message-ID: <11379@goofy.Apple.COM>
Date: 29 Nov 90 18:38:55 GMT
References: <23645@grebyn.com>
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 54

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.

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.

3. Expressiveness - Designing the methods of a class is like defining a 
language for manipulating objects of that class. Make sure your message 
set is expressive, and you have a big win. There is no good way of 
measuring expressiveness that I've ever seen, but some thought about ways 
you might wish to refer to the object as a generic construct will often 
give you insights into ways to make its message set expressive. Approach 
each class design as an exercise in language design.

4. Consistency - Does your class have messages which resemble messages 
used for similar operations in your class library. Obviously, a more 
consistent system is more comprehensible. This postpones the inevitable 
point where your system becomes too large for anyone to master, and you 
must implement cumbersome bureaucratic controls to attempt to maintain 
system integrity.

5. Relevance - How much does your class take advantage of existing classes 
in its operation. If you are not making extensive use of the class 
library, you are giving yourself unneeded headaches with maintenance and 
integrity. Examine classes for use of common algorithms and structures, 
and decide if another object class can be either used or generated to 
centralize the needed functionality. Remember the Abstraction criterion, 
though, and rely on protocol instead of explicit class reference!

Hope these are of some use to you!

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

Disclaimer: My opinions are my own, NOT Apple's. So There.