Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site unc.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxb!mhuxn!mhuxm!mhuxj!houxm!whuxlm!akgua!mcnc!unc!glassner From: glassner@unc.UUCP (Andrew S. Glassner) Newsgroups: net.lang,net.lang.st80 Subject: Re: Definition of Buzzwords: "Object-Oriented" Message-ID: <112@unc.UUCP> Date: Fri, 25-Jan-85 12:39:52 EST Article-I.D.: unc.112 Posted: Fri Jan 25 12:39:52 1985 Date-Received: Mon, 28-Jan-85 05:10:11 EST References: Reply-To: glassner@unc.UUCP (Andrew S. Glassner) Distribution: net Organization: CS Dept., U. of N. Carolina at Chapel Hill Lines: 64 Xref: watmath net.lang:1308 net.lang.st80:164 Summary: The posting on OO buzzwords asked for definitions of the term "object- oriented". To me, the words describe a point of view and a style of implementation. The point of view is that the procedure/data relationship is flipped over from that of most other languages, e.g. Algol, APL, Snobol, etc. Thus, instead of having a general procedure "cut" that accepts the two pieces of data "scissors" and "paper", we have an object "scissors" that is given "paper" and told to "cut". The meaningful thing for me in this view is that relationships between objects (data in the Algol view) are *implicit*, not explicit. If a balloon object is told that air is arriving at the hole, it will blow itself up. It doesn't need to know from where that air arrives, and the balloon does not need to be told in its code of all the different places from which air can arrive. The style of implementation of object-oriented code is that of self-contained, encapsulated "objects" (or collections of procedures, or "methods") that communicate with each other via "messages", or commands. This takes the popular notion of "hiding" important information or local data to a fully-implemented conclusion. Each object is responsible for its own local information (the data which describe it and the messages to which it can respond), and nobody else can touch that information. Other objects may ask to see it or ask to change it, but only the owner of the information has direct access to it. In my perception, the difficulty in defining the term object-oriented rests in a subtle point of view. In general, when one is learning of a new idea (or having a new idea defined), a major question is "Why am I being told this?" The usual expectation is that the new concepts or techniques are somehow *better* than other techniques, and indeed this is the usual reason people try to expose us to other ways of doing things. To compter-science people, "better" often means "more powerful", or "more expressive". Thus, APL is "better" than ALGOL because it can express complicated ideas in compact space, whereas ALGOL is "better" than APL because it is more readable. The problem is that the object-oriented point of view, when described statically, appears no more "powerful" than the traditional procedure/data model. Thus, why bother to spend the time and energy to learn it? I feel the justification comes from the point of view that the programming model we work with profoundly affects our work. This isn't a new idea; the example is often made that the spoken language you use affects the way you think and approach problems. So although the "object/method" view may not immediately seem more "powerful" than the "data/procudure" view, it is a different way to describe the work to be done. If the new point of view is as powerful as the old (which it is), and if it is truly a new point of view (which can be argued, but only after one understands it!), then that is justification in itself for its study. To my mind, the OO point of view is "better" because it lets me formulate my problems in terms of implicit relationships between intelligent data, rather than explicit manipulations of information. I suggest that the above may also serve as a defintion of "object-oriented". -- -Andrew Andrew Glassner decvax!mcnc!unc!glassner