Good Design Strategies <Was comments on comments>

[rjh@cs.purdue.EDU (Bob Hathaway)]

In article <2325@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes:
> In an article by rjh@cs.purdue.EDU, Bob Hathaway says that he usually
> uses ADT's to do top-down design and implementation...

Umm, the method presented was better categorized as a modular design
strategy with abstract data types.  The implementation strategy was
Adt/object oriented because coding began by implementing the Adts.  In 
top-down/bottom-up terminology this corresponds to top-down design with
bottom-up implementation.  This strategy can be applied recursively
to Adts with the top level object as the starting point in design
and the bottom level sub-objects as the starting points in implementation.
We know that we need an intermediate code Adt, which may require a generic
tree Adt, which may require a generic list Adt, and so on.  It seems
natural to first identify the intermediate code Adt as necessary in the
overall system design but to begin its implementation at the bottom level
by using generic components.

Since the following is long, I'll ask here.  It would be interesting to see
some discussion on design strategies; any interesting opinions or experiences?

> I too have been designing all my programs around "abstract data-types"
...
> But I don't usually do top-down.  I do bottom-up.  Design, implementation,
> test, everything.  It actually shocks some people when I say that. In the
> seventies "bottom-up" became a dirty word.  Never mind that top-down
> methods resulted in some of the most inflexible code every put to disk.
> Top-down good. Bottom-up bad. Unnngghh. :-)

What you describe sounds like an Adt/object oriented implementation, I'm not
sure if the bottom-up arguments apply.

> I'll freely admit, there are times when top-down is the way to go.  But
> it's not the way I do most of the programs I write by myself.
> 
> I start out with a "bottom" that consists of lots of -- okay, I'll go 
> along with the name -- ADT's which are likely to be of use in just 
> about any kind of program: lists, queues, hash-tables, avl-trees, 
> flexible buffers, priority queues and so on.  Next I use these to form 
> ADT's which are specific to the low-level objects under consideration, 
> etc.  And so it goes from bottom to top.  The payoff comes when you want
> to change something. All you have to do is reshuffle these building blocks,
> which are still quite useful. But if you go from the top to the bottom, 
> a change at the top is likely to invalidate the whole blasted thing.

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.

> I sometimes carry it to unlikely extremes.   My group is writing a Pascal 
> compiler. If ever there seemed to be a top-down kind of task, that seemed to be
> it.  I mean, Pascal is already done, for Pete's sake.  There are standards
> documents which tell you what a Pascal compiler absolutely *has* to do. But..
> I started out with my bag of standard ADT's anyway, and then defined some
> more: Pascal blocks, types, parms, variable-accesses...  just about
> every kind of Pascal-object you can think of.  One by one we implemented
> them as we worked our way up to type-definitions, expression-trees, statements.
> The methods for these ADT's went into a library.
> 

This sounds like a bottom-up implementation, but since the upper levels
(objects) were already known in advance, a top-down design (loosly speaking).

>It was only a matter of a few weeks, long before the compiler's high level
>was anywhere near finished, that it paid off.  Another group was doing
>a mouse-driven frontend for the interactive embedded compile/load/go
>feature that we have.  They needed to be able to capture all of the
>type-information, formal parameters and so forth about the program being
>run, then fish around in it finding all the variables of this type,
>building all the short expressions that are assignment compatible to the
>second formal parm of procedure foo, etc..
>...
>
>Try doing that with a Pascal compiler that was designed top-down to
>be a Pascal compiler.

It sounds like the bottom-up implementation provided them with the working
software early.  A good design will provide reusable components which are
easy to modify regardless of the implementation.

Bob Hathaway
rjh@purdue.edu