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.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.software-eng:1155 comp.lang.ada:2061 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!mcvax!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.software-eng,comp.lang.ada Subject: Re: Good Design Strategies Message-ID: <4343@enea.se> Date: 27 Feb 89 09:09:34 GMT Organization: ENEA DATA AB, Sweden List-Id: Bill Wolfe (wtwolfe@hubcap.clemson.edu) writes: Rob Jellinghaus (jellinghaus-robert@CS.YALE.EDU) said: >> 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. > > I'd suggest Booch's coverage of object-oriented design in > "Software Components with Ada" instead; Meyer's book comes > bound up with a rather flaky programming language. I don't want to start an Ada vs. Eiffel debate, but the view that Eiffel is a flaky language is something Bill Wolfe have to stand for himself. What I like to stress is: Ada is *not* an object-oriented language. I used to think that, but there are just to much missing. Particulary inheritance and dynamic typing. And although this is a trivial fact to realise, it still seems necessary that from time to time make a reminder about this. Due to Gary Booch and others it is easy for the casual reader to get the impression that Ada <=> object-oriented programming. But it's true that Ada is better for applying object-oriented strategies than most other "conventional" languages. As for bottom-up vs. top-down, Meyer explains this very well in his book, and it's certainly applicable to the recent discussion. One drawback with top-down I haven't seen well covered, is the big risk that you never see that two leaves are the same, or see it too late, so you get the same code in two places. (Or even worse, you should have two identical pieces of code, but in fact they are different.) The project I'm in right now was designed top-down, if it was designed at all. (It's a real mess, but don't blame me I came in too late.) And it is a clear mistake. OK, there is a set of library routines for low-level objects like formatting routines and simple database accesses. But very little for handling of high-order objects like account statements and other application specific things. I have tried to introduce it, but when you need more than a day for it, you get in conflict with the time schedule, whichh of course give no place for "luxury" like that. -- Erland Sommarskog ENEA Data, Stockholm This signature is not to be quoted. sommar@enea.se