Xref: utzoo comp.software-eng:385 comp.lang.c++:937
Path: utzoo!mnetor!uunet!husc6!think!ames!amdahl!dlb!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.software-eng,comp.lang.c++
Subject: Re: Object Oriented Design
Message-ID: <421@goofy.megatest.UUCP>
Date: 31 Mar 88 02:57:19 GMT
References: <1711@devvax.JPL.NASA.GOV>
Organization: Megatest Corporation, San Jose, Ca
Lines: 59

in article <1711@devvax.JPL.NASA.GOV>, des@jplpro.JPL.NASA.GOV (David Smyth) says:
> 
> In article <2045@munnari.oz> taso@munnari.oz (Taso Hatzi) writes:
>>
>>I am seeking comment on the following questions from people who have 
>>had success with any object oriented design methodology.
> 

[...]

>>
>> o Do there exist any well known object oriented design methodologies?
>>
> 
> 1. understand the problem however you need to.
> 2. figure out the general objects required, and what look like (attrs),
>    what they act like (methods).
> 3. formally list and describe the attrs and methods for each object.
> 4. implement the objects, most general first, most specific last.
                            ^^^^ ^^^^^^^ ^^^^^  ^^^^ ^^^^^^^^ ^^^^

> [...]

I quite agree.  But this statement can be misinterpreted.  So let me
rephrase it, "Implement the classes, in a bottom-up (not top-down!) order."
Or stated another way, "Implement base-classes and so-called 'library
classes' first.  Then do the derived classes and high-level classes."

That is what you meant, right?

-- HERASY ON --

The "top-down design" philosophy goes hand in hand with "structured
design" as a means for enforcing software rigidity and closed systems.
"Piecewise refinement" is the best way I know to insure that a software
design is so tightly targeted at a specific set of high-level
requirements, that any change will propogate changes throughout 
the entire system.  Change something near the top of a "piecewise 
refined" program, and you will find that you are obliged to piecewise 
refine it all the way to the bottom all over again.

Brad Cox said it about as well as I have heard anybody say it, in his
Objective C book.  I don't have the book handy, but essentially he
said that the _requirements document_ is a Marginot Line behind which
one may hide from the enemy: The enemy is Change.  (Too bad Brad 
thinks he invented software libraries.  Calls the library classes
"software IC's", you know. I just don't have the heart to tell him
otherwise.)

Here's a toast to to "piecewise concretion".  BOTTOMS UP!

-- HERASY OFF --

Now may the incredulous rejoinders commence.  I think I'll take a few
days off in, oh.. say, the Peepee islands maybe.



		-- Dave J.