From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.software-eng:1147 comp.lang.ada:2057 Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!cmcl2!yale!jellinghaus-robert From: jellinghaus-robert@CS.YALE.EDU (Rob Jellinghaus) Newsgroups: comp.software-eng,comp.lang.ada Subject: Re: Good Design Strategies Message-ID: <51955@yale-celray.yale.UUCP> Date: 26 Feb 89 19:34:48 GMT References: <6100@medusa.cs.purdue.edu> <2344@goofy.megatest.UUCP> Sender: root@yale.UUCP Reply-To: jellinghaus-robert@yale.UUCP Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 List-Id: 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_