Re: Good Design Strategies <Was comments on comments>

[jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus)]

In article <2344@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
>From article <6100@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway):
>> The standard argument for top-down design is that design errors are caught
>> early.  A top level change could make all the work done at the bottom level
>> unnecessary and major rewriting or complete scrapping could occur.  That
>> is the advantage of top-down design with bottom-up implementation, the
>> overall design should be close to correct and the implementation is direct
>> and fast because the objects and procedures don't depend on anything not
>> yet implemented.  I think the advantage of "building blocks" should be
>> evident in any design since code which is designed to be easy to modify
>> will consist of reusable and parameterized components which correspond
>> to a loosly coupled and highly cohesive modular design.
>
>If you end up with "reusable and parameterized components ... loosely
>coupled... modular", then it doesn't matter how you got there.
>My argument is that in most cases, you are more likely to end up
>in such a software ecstacy if you use bottom-up design techniques,
>and you'll get there quicker.

Everyone involved in this discussion should get their hands on a copy
of Bertrand Meyer's book _Object-Oriented Software Construction_, Prentice-
Hall, 1988.  The design philosophy being discussed sounds virtually
identical to Meyer's exposition of the object-oriented design method.

Briefly, Meyer's summary of object-oriented design is as follows:

	Ask not what the system does, ask what it does it to.

In other words, the most important characteristic of the system is NOT
its overall "intended function".  The most important description of the
system is in terms of the objects, the data, that is manipulated by the
system.

This is more akin to bottom-up design than to top-down design, for sure,
although the emphasis is slightly different.

>You say, "A top level change could make all the work done at the bottom level
>unnecessary and major rewriting or complete scrapping could occur."
>
>HATE IT when that happens!
>
>That is one reason why I design the low-level objects first.  If they are
>designed without knowledge of the specifics of the higher levels, high
>level changes cannot effect them.  The disaster happens when somebody
>"finishes" the high level design and then designs the bottom level around
>that, and then Ooops! -- it turns out that the high level design had a flaw
>in it. Then you discover that the change propogates right down through
>all the levels.

The typical top-down design spec is functionally oriented; i.e. "We want
the system to Do This, and in order to Do It, it'll have to do this, and
this, and this..." etc., etc.  When you change your mind about what you
want it to Do, you're hosed.  Object-oriented style avoids this, by focusing
the design effort on the structure of the data to be handled, rather than
on the design of the whole system.  A proper object-oriented design is
inherently modular, and seldom needs a complete revision; the modules are
organized in a network rather than in a hierarchical tree, which means
changes to the net can be made without affecting the whole system; whereas
if you need to change the root of a top-down tree, you're hosed.

>I gave a case history of using the parts of a Pascal compiler in
>a mouse-clicky kind of editor. I'll reply to one comment.
>You said, "It sounds like the bottom-up implementation provided them
>with the working software early."
>
>I say, The bottom-up design provided them with software that didn't
>"know it was in a compiler".  Recall, I did not even know about that
>project when I started the compiler.

Exactly.  Your objects were general enough to be free from a specific
system.  This is reusability, and Meyer talks about how to get it.  A lot.

>I have tried to use the parts of other production compilers
>to do things other than pre-runtime compilation. Not as an academic
>exercise, but to produce real commercial products.  That's why I'm
>writing this one!  I would rather buy the source for one off the self.
>Better yet, what I would really like is what I am writing: a library of
>low and mid level Pascal object Adt's. Then I wouldn't even need the
>source, except to fix bugs and port it to new platforms. But try to
>find such a thing: an open architecture compiler.  So far as I know, I
>am writing the first one.

You should definitely go out and take a look at this book.  One of Eiffel's
(Meyer's language) main selling points is its reusable object library,
with everything from arrays to hash tables to an Xwindows library already
coded.  (According to reports, lexical analysis and (someday) concurrency
libraries will be available too.)  Sounds right up your alley!

Rob Jellinghaus                | "Next time you see a lie being spread or a
jellinghaus-robert@CS.Yale.EDU |  bad decision being made out of sheer ignor-
ROBERTJ@{yalecs,yalevm}.BITNET |  ance, pause, and think of hypertext."
{everyone}!decvax!yale!robertj |     -- K. Eric Drexler, _Engines of Creation_