wlp@calmasd.Prime.COM (Walter Peterson) (09/13/89)
I have received a number of e-mail messages regarding my posting about object-oriented design (OOD) books and several of them have asked the same question so I'm clarifying it here for one and all. In the posting I stated that I have not seen any good object-oriented design books. Several people have asked me if I meant this or that specific book. Let me say that I was being quite specific about Object-Oriented *DESIGN* books. There are several excellent books that, while they do address OOD, are primarily about a sepcific language and the techniques and principles of OOD as they apply to those languages. Bertrand Meyer's "Object Oriented Software Construction" is one such. This is a very good, very well written book and on the whole I would recommend it. Another very good, albeit somewhat dated (1986) book is Brad Cox's "Object-Oriented Programming: An Evolutionary Approach." Both these and certain others ( the set of books on Smalltalk-80 by Goldberg, et. al. ) are all very good. However, they all approach object-oriented design from the viewpoint of the particular language which they are presenting. This is not in and of itself a bad thing, but it does color their presentation of the object paradigm and the principles of object-oriented design. Cox for example, devotes only a few paragraphs to multiple inheritance, since at the time of that writing ( and today ? ) Objective-C did not support multiple inheritance. He is quite up-front about that and in that context I have no problem with the omission of multiple inheritance. If he had been caliming to be writing about the general, overall object paradigm and general object-oriented design methodology, I *would* have had problems with it. I am still looking for two things: 1. a good, general, overall introduction to the object paradigm and object-oriented design methodologies that is not tied to a single language and 2. any good, ACCURATE, READABLE introduction to C++. The need for an instance of item 2. is almost self-evident if one has been following the discussions here of the various C++ books currently available. I won't belabor it any further in this posting. My concern for an instance of item 1 may not be so obvious, however. OOP is still trying to define itself. There are a number of good OO languages available, a number of so-so languages and a few not-so-hot languages. No two take exactly the same approach to OOP. Some use inheritance, others deligation ( some say deligation is inheritance; I'm not going to get into *that* debate here ! ) some have multiple inheritance, others don't. Of that ones that do have MI almost no two do it in the same manner. Some have dynamic class hierarchies and do more at run-time than the ones that do not. The list of differences goes on and on. Some of these differences don't impact on design decisions, but others can have a significant impact on the design. In previous postings I have taken some people to task for the object models that they have presented on the net and I believe that the main reason for these poor models has been a lack of understanding of the general principles of OOD and excessive concentration on the mechanics of a particular language. I'd better cut this off at this point or I'll run on for too long. Input is welcome and actively solicited. --------------------- -- Walt Peterson. Prime - San Diego R&D (Object and Data Management Group) "The opinions expressed here are my own."
brucec@demiurge.WV.TEK.COM (Bruce Cohen;685-2439;61-028) (09/15/89)
In article <583@calmasd.Prime.COM> wlp@calmasd.Prime.COM (Walter Peterson) writes: >In previous postings I have taken some people to task for the object >models that they have presented on the net and I believe that the main >reason for these poor models has been a lack of understanding of the >general principles of OOD and excessive concentration on the mechanics >of a particular language. There is also a regrettable tendency even among the well-informed to be careless in their use of OO terminalology (even when the proponents of different languages agree on the meaning of the terms). I find a classic (pun intended) example of this just today in the Lippman book. I could not remember how to mix member initializations with arguments to superclass constructors in a constructor definition, and I spent fifteen minutes finding the right section in the book, because the title of the section is "Class Initialization", which I took to mean initializing a class's classvars, not the initialization of instances of a class. Now, as you can see from *my* terminology, I learned Smalltalk as a first OOL, and I tend to hark back to it. I find that I have to sometimes, because C++ terminology is either impoverished (I'd much rather say "superclass", than "immediately ancestral base class"), or the meaning of terms is fuzzy from ambiguous use (many people use "object" and "class" interchangeably to mean "instance of class object"). Be clear that I'm not picking on Lippman; his book is my standard reference for the syntax and semantics of C++, and has been since the day I got it. I am saying that there is a body of theory and practice in OO languages, systems, and programming, and that much of that existed before C++, and is applicable to C++. Not applying it means that distinctions not clearly made by the programming language are not clear to the designer/programmer, who has no other abstractions to use in thinking about these areas. This makes such areas a source of loss of expressiveness and design options, and potentially even a source of error in programming. Bruce Cohen brucec@orca.wv.tek.com Interactive Technologies Division, Tektronix, Inc. M/S 61-028, P.O. Box 1000, Wilsonville, OR 97070