Path: utzoo!attcan!uunet!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.object
Subject: Re: How do you evaluate objects?
Message-ID: <77500067@m.cs.uiuc.edu>
Date: 30 Nov 90 14:29:00 GMT
References: <23645@grebyn.com>
Lines: 26
Nf-ID: #R:grebyn.com:23645:m.cs.uiuc.edu:77500067:000:1361
Nf-From: m.cs.uiuc.edu!johnson    Nov 30 08:29:00 1990


I think that any discussion of what is a "good" object should
recoginize that objects should not be designed in isolation.
Instead, a system is made up of many objects, and they must
be designed to work together.  Thus, it is important to have
a few very flexible interfaces, and most of your objects should
fit into one or more of the interfaces.  

The suggestion that a method should do one thing is important,
and is a special case of the general system design rule that
each component should do one thing.  Of course, since an object
has many methods, it might seem impossible for an object to do
one thing and for its methods to also do one thing, but "one"
is relative.  The phrase "do one thing" really means that it
should be possible to describe what the component does in a short
sentence and that you should never have to use just half of the
component.  A Button might be able to display itself and to react
to a mouse click, but it still embodies one main idea.

Another thing to remember is that some of the objects are part
of the problem domain, while others are part of the solution domain.
You should not expect users to understand (or even care) about the
objects that are in the solution domain.  In fact, it is best to
hide their existence from the users as much as possible.

Ralph Johnson -- University of Illinois at Urbana-Champaign


Brought to you by Super Global Mega Corp .com