Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!mcnc!unc!rentsch From: rentsch@unc.UUCP Newsgroups: comp.lang.misc Subject: Re: Teaching object-oriented paradigm to beginners? Message-ID: <624@unc.unc.UUCP> Date: Sat, 17-Jan-87 02:39:56 EST Article-I.D.: unc.624 Posted: Sat Jan 17 02:39:56 1987 Date-Received: Sat, 17-Jan-87 16:34:25 EST References: <4000001@nucsrl.UUCP> <3288@milano.UUCP> <147@m10ux.UUCP> Reply-To: rentsch@unc.UUCP (Tim Rentsch) Organization: CS Dept, U. of N. Carolina, Chapel Hill Lines: 102 In article <147@m10ux.UUCP> mnc@m10ux.UUCP writes: > Why is it so hard for O-O programming advocates to explain the advantages > of their programming methodology without slipping into obscure, specialized > O-O jargon, or invoking the religious argument, "well you can't under- > stand why it is better until you've done a large amount of O-O programming > yourself"? I would say this differently. It is not that you can't understand it, but that it is difficult for me to *explain* it until you have done some (not necessarily large) amount of O-O programming yourself. This difficulty seems to happen in spite of my best efforts, witness my paper "Object Oriented Programming", SIGPLAN Notices, Sept 1982. [Incidentally, the paper was written for just that reason -- to explain what OOP is to someone who had not done any -- and it did not succeed.] As to why explaining OOP is so hard: I suspect an understanding of OOP requires a paradigm shift, and paradigm shifts are just inherently difficult, especially without the experience of trying them. Remember the difficulty the quantum mechanics people had in the 1920's and 30's? Even Einstein, a brilliant physicist, was reluctant to see things from the QM point of view, but now QM is an accepted part of physics. The difficulty there was the (radical) paradigm shift that QM required before it could be understood. > What is the difference (other than a rather contrived, anthropomorphic > view of the relationship between functions and values), between O-O > programming and the ten (?) year old theory and practice called "abstract > data types"? The fundamental belief with technical importance in > both methods (with which I completely agree) is that pieces of programs > should be divided into chunks that have a precisely documented interaction > with other chunks, but the internals of which are completely unknown (or > irrelevant to) other chunks. Put more concisely, "separate WHAT it does, > from HOW it does it, so that the HOW can be changed without affecting the > WHAT". Isn't O-O programming simply a special case of, i.e. one particular > method for achieving, abstract data types? It seems to lie completely > under the definition of an abstract data type as a collection of types > and functions on those types, together with the notion that we can have > multiple objects of the abstract data type. OOP is not (in my opinion, at least!) simply a special case of abstract data types. Here are several reasons, ranging from specific and particular to more general (which you may feel are vague and contrived -- even so I present them). I only hope that among the various reasons presented, some point will strike home. [I use Smalltalk as the archetypal OOP language.] In Smalltalk, variables (and parameters) do not have a type, in the sense that a type is known at compile time. With abstract data types this is not so -- even though we don't know how the operations work, with ADT's we at least know what the operations *are*. In Smalltalk we don't even know that. Now, you can argue about whether this difference is good or bad, but it is certainly a difference, and I claim a significant and useful one. Second, classes in Smalltalk do not have "precisely documented interactions" in the sense that even if you know the class of some variable, you don't know anything about the operations except their names (and so how many parameters each operation expects). In particular, there is no specification of what function the operation will perform, or even of what "type" of arguments are required. Again, contrast this to ADT's, which do have specifications. You might believe that this makes ADT's superior to OOP -- on which point I disagree -- but even so you must admit this is a difference. (Why that difference makes OOP better is another matter.) Most ADT's cannot express very polymorphic operations, for example stacks of mixed types (not to be confused with type parameterized stacks, which can be instantiated multiple times for different types). In Smalltalk, it is trivial to write a class definition for a stack which can mix integers, floats, rectangles, and even other stacks within a single stack. The ease of writing very polymorphic code clearly distinguishes OOP from ADT's. "Separate WHAT it does, from HOW it does it" certainly characterizes ADT's. But "this is what should be done" is not what I think of as OOP; rather it is more like "what I WANT is blah", but leave the decision of what is to be done (more than just how to do it) up to the object. I realize this may seem like a fine distinction (or perhaps no distinction at all), but I assert that the distinction is real and significant. (The vaguest explanation of all, but still, I hope, useful.) An ADT is, indeed, a "collection of types and functions ON those types" [emphasis mine]. In OOP, on the other hand, data and function are inextricably linked -- rather than functions operating on data, operations are intrinsic to the object just as much as data is intrinsic to the object. Data and operations cannot be separated in OOP; they are separate in ADT's, only collected together for the purpose of presenting the data type to the "outside world", but internally they are still separate. Just as I believe your questions were asked sincerely, so I have tried to give sincere and informative answers. Hope they helped. (See also the paper reference earlier.) cheers, Tim