Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.object
Subject: Re: Objects and Interactions: Separate Definitions
Message-ID: <7051@stpstn.UUCP>
Date: 24 May 91 20:15:52 GMT
Article-I.D.: stpstn.7051
References: <3999@motcsd.csd.mot.com> <1991May21.064913.16149@netcom.COM> <1991May22.012821.12048@tkou02.enet.dec.com> <1991May22.183044.5634@Think.COM> <19807@crdgw1.crd.ge.com>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Distribution: comp
Organization: Stepstone
Lines: 55

There's a famous misconception that I call 'The Sucker Trap of OO Programming',
that you should design by identifying the nouns and the verbs; then make 
the nouns instances and the verbs methods. 

This is not to attack Grady who first formalized this as a design recipe. 
All of the early advocates, myself specifically included, are guilty of 
encouraging this notion in our rush to explain how OO differs from 
conventional data and procedures.

Now that encapsulation of data with procedures is widely accepted as good,
it is now quite proper to ask 'Now that we can have honext to goodness entities,
how to express the relationships?

Except at the very lowest levels of granularity where this is often proper,
a much better way is to distinguish between *active* objects and *passive*
objects. Both are objects, but one sort is more heavily weighted with data
and the other with procedure. In your terminology, the passive objects are
the entities, and the active ones the relationships.

This is nothing more than the Smalltalk model-view-controller paradigm
generalized to apply not only to user interface construction, but as a 
broadly applicable principle of good design.

The phrase, 'levels of granularity' in the preceeding paragraph, opens up
a whole new can of worms that I wish more people would concentrate on. A
generally recognized vocabulary for architectural levels would greatly
clarify many of these discussions.

For example...most people's notion of objects/messages is one level of
granularity. Because of the Software-IC notion, think of these as 
chip-level objects in order to leave room for lower-level kinds of
objects such as friend/member functions (block-level objects) and
inline procedures/macros (gate-level objects).

Compose from these chip-level objects a higher-level construction involving
active and passive chip-level objects working in combination, such as
perhaps a Smalltalk user interface involving model-view-controller.

What should we call this higher-level construction? Why not 
a card-level object, to suggest a new kind of object at a higher level
of concretion. Or suppose that this user interface is part of a larger
application that involves a number of lightweight tasks. Aren't these
'objects' too, at an even higher level of granularity than the others?

I'm not hung up on the precise set of words here. I'm only arguing that
different levels of *concretion* (*not* abstraction) do exist in software, 
and that we desperately need a vocabulary (apart from the object/message 
vocabularity) to point out which level of granularity we're talking
about.


-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482