Path: utzoo!mnetor!uunet!yale!bunker!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.lang.c++
Subject: Re: Object Design Tools
Message-ID: <1681@stpstn.UUCP>
Date: 10 Mar 88 22:11:00 GMT
References: <97@cui.UUCP> <36300003@pyr1.cs.ucl.ac.uk> <1442@devvax.JPL.NASA.GOV>
Organization: Productivity Products Int'l, Sandy Hook, CT
Lines: 81
Summary: Object-oriented design; Perhaps necessary but certainly not sufficient

> In article <36300003@pyr1.cs.ucl.ac.uk> winnie@pyr1.cs.ucl.ac.uk writes:
> 
> OOD Methodology (derived from Booch, Cox, and MANY others):
> 
> 1)	Understand the problem any way you want to.  Maybe throw together a 
> 	prototype.  I don't care - understanding the problem is beyond the
> 	scope of "design."
> 
> 2)	Write an informal description of the problem.  This is just prose.
> 
> 3)	Identify the "objects" in the informal description (nouns, and
> 	identifying prose).
> 
> 4)	Identify the attributes of the objects (descriptive prose) and the
> 	methods applied to the objects (active prose).
> 
> Well, that does it for the OOD methodology.  Pretty easy isn't it?  Try it,
> you'll like it - everybody else has! 

I must admit to the same kind of discomfort I've felt many times before with
Structured Programming/Design and now OO Programming/ Design. Which is that
such adjectives encourage the gullible to view them as indistinguishable with
GoodProgramming and GoodDesign.

I really like your caricature of OOD. It neatly captures in very few words
the shallowness of OOD as a topic unto itself and how far we've yet to go
to arrive a complete GoodDesign cookbook.

I've done a lot of system-building, have made a lot of mistakes, done a lot 
of things right, and have tried to learn from all this to begin building such
a cookbook. My primary recipe is a simple one

	USE THE RIGHT TOOL FOR THE JOB

That is nearly any tool, C, assembly language, Smalltalk, Unix, awk, shell, 
Cobol, Structured Programming, Object-oriented programming, has a right place
and a wrong place *inside nearly every programming project*.

I particularly like this rule because it totally subsumes fads by presuming 
that any skilled craftsman will stay abreast of the state of the art in
his area and will be aware of important tools as they come available,
be they structured programming, object-oriented programming, and the like.
The skill is then a matter of deciding which tool is right for the job at
hand.

The second rule is more radical and more specific. And like the first one,
you won't find it mentioned in any of the OOD cookbooks I've seen to date.
In fact, it is so seldom discussed that I've given it a fancy name to
attract the attention that it deserves, *The Golden Rule of Design*.

	SEPARATE THE ABSTRACT AND THE CONCRETE

I learned this one from the Smalltalk-80 Model-View-Controller paradigm, 
by reading Alan Shaw's discussion of text-formatting programming, and by 
paraphrasing one of the dictums of data-flow diagramming as *Keep the bubbles
distinct from the arrows*; i.e. separate the data from the processes that
are transforming it. Paraphrased for object-oriented programming, it
means to separate those classes that represent the abstract behavior
of the application (the models) from those classes that are involved
in transforming the model (the views and controllers), because abstractions
can usually be codified to withstand radical evolutionary change far
better than transformation classes, particularly when the transformations
have to do with user interfaces.

A correlary of this rule is to avoid what I now refer to (after having 
*recommended* it several times in writing! That is, before I knew better)
as a sucker trap that object-oriented programming lays for the unwary, 

	OBJECTS SHOULD NEVER KNOW HOW TO `PRINT' THEMSELVES 
		(or `display' themselves, nor any analogous verb).

Printing is guaranteed to change because it depends on display device
technology, formatting requirements, and even the needs/expertise of the 
viewer, while abstract (model) objects can live on and on without change.


-- 
	Brad J. Cox, Ph.D.
	Productivity Products International
	75 Glen Road; Sandy Hook, CT 06482
	(203) 426 1875; ...yale!bunker!ppi!cox