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 autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!JPL-VLSI.ARPA!larry From: larry@JPL-VLSI.ARPA Newsgroups: comp.lang.ada Subject: Ada texts + Object-Oriented Programming Message-ID: <861217015204.00g@Jpl-VLSI.ARPA> Date: Wed, 17-Dec-86 04:52:04 EST Article-I.D.: Jpl-VLSI.861217015204.00g Posted: Wed Dec 17 04:52:04 1986 Date-Received: Thu, 18-Dec-86 01:48:37 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: Eileen, I at least read the first chapter of most Ada books that come out and I still recommend Grady Booch's Software Engineering with Ada for most beginners. Note that Booch just came out with a third edition. I'm also impressed with Putnam Texel's book. For Pascal experts Habermann & Perry's Ada for Experienced Programmers is good, with many examples all worked out both in Pascal and then in Ada. Narain Gehani and Norm Cohen each have a book that is a bit more advanced than Booch or Texel. J.G.P.Barnes text jumps right into nitty-gritty, which some people like who disdain "all that software engineering propaganda." But don't take anyone else's word for the one (or more) book(s) you need. Skim the first chapter, look at the table of contents, and read the introduction, then pick the clearest one. ************************ One element of Booch's book may not be clear: object-oriented programming. I assume this because at conferences and in various Ada articles at least half of the people who sling the term around don't seem to know what it is, and most of the others are too close to details of how OOP is done to see the overall picture, the commonalities shared by Ada, SmallTalk, LisP Flavors, and so on. I hope the following clears this up (and maybe stimulates some discussion on this list). An object in a programming language is an analog of some external object. The most important characteristic of both is a boundary of some kind. The important dimensions of the boundary depends on what problem you want the computer to solve. An engineer designing computer circuitry might be interested in digital pulses, with two crucial dimensions, time and voltage, which form the beginning, end, "top," and "bottom" of each pulse. Many objects have not only boundaries but a skin at the boundary. This protects the interior from the exterior, and vice versa. The more advanced programming languages also have these skins: in Ada each compilation unit has a specification which serves this purpose. (The unit with the "strongest" skin is the package.) There is also typically some control over the "permeability" and "transparency" of the skins: in Ada private types, the Shared Pragma, and a few other features perform these functions. Another aspect of objects is that they fall into classes which have the same attributes and capabilities. This is useful if you can create subclasses of objects that inherit attributes/capabilities from the superclass; this saves the programmer from duplicating the effort of specifying what is inherited. In Ada derived types, generics, and (in one sense) overloading are inheritance mechanisms. Other languages provide additional or alternate mechanisms to support object-oriented programming. Whatever the language, each mechanism always has advantages and costs. The software engineer makes trade-offs to produce an optimum system. For instance, SmallTalk is more useful than Ada for producing and modifying prototypes; Ada produces much more efficient code. Object-oriented programming is really an attitude rather than a collection of mechanisms; it can be used in relatively primitive languages such as ForTran or Assembler. OOP focuses the programmer's mind on the enduring components of the desired system, which tends to produce programs that need little change or can be easily changed. It also promotes designs that use elements from the problem area; that is, the programmer tends to think in terms of spaceships and thrusters rather than data structures and subprograms, or invoices and sales, etc. This takes advantage of the knowledge and intuitions the programmer has from (or so we hope!) knowing the problem area. It also tends to reduce the sort of "painted into a corner" errors that come about when programmers jump into coding without thinking through all the requirements of the system they're developing. OOP is sometimes thought of as antagonistic to older ways of designing systems. My feeling is that it is more of a superset of previous approaches. Functional decomposition focuses on the activities of a desired system, data-structure approaches focus on static data relations, data-flow combines the two with an emphasis on activities and with a more implementation-oriented mindset. As with any tool, there are limits and problems with OOP--something which no-one I know in the Ada community has addressed. I have to admit I haven't done much along those lines myself. It does seem to me that there are probably problem domains in which OOP would have problems, say areas where objects with boundaries don't exist. And there may be problems that could better be solved by a more mathematical or symbolic-logic approach. Larry @ jpl-vlsi.arpa