Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site mako.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxj!houxm!vax135!cornell!uw-beaver!tektronix!orca!mako!jans From: jans@mako.UUCP (Jan Steinman) Newsgroups: net.lang,net.lang.st80 Subject: Re: Definition of Buzzwords: "Object-Oriented" Message-ID: <535@mako.UUCP> Date: Wed, 23-Jan-85 13:04:18 EST Article-I.D.: mako.535 Posted: Wed Jan 23 13:04:18 1985 Date-Received: Fri, 25-Jan-85 05:18:33 EST References: <4288@ucbvax.ARPA> Reply-To: jans@mako.UUCP (Jan Steinman) Distribution: net Organization: Tektronix, Wilsonville OR Lines: 56 Xref: watmath net.lang:1291 net.lang.st80:158 <4288@ucbvax.ARPA> wildbill@ucbvax.ARPA (William J. Laubenheimer) writes: >I have recently been involved in some discussions in which the topic >of so-called "object-oriented" languages and programming techniques >has been explored... (we are) having a hard time coming up with a rigorous >definition of those terms... > >1) The term is self-explanatory: the orientation of the language/program > is towards the "object". This causes the discussion to move in > the direction of defining an "object", and how exactly the language > or program is oriented in that direction. I essentially agree with this argument, but see no problem providing a rigorous definition of an "object", which is, most generally, a cohesive collection of data and allowed operations on that data. Within an object data-function binding is high, while between objects, a loose coupling mechanism is used to protect the integrity of those objects. "An object consists of some private memory and a set of operations... Objects representing numbers compute arithmetic functions. Objects representing data structures store and retrieve information." [1:p6] The crucial point is the collection of data AND functionality. Traditional languages keep the two apart and allow functionality to operate ON data. Object oriented languages have objects knowledgeable in the kinds of things they may do to their data -- these objects honor requests from other objects to do these things. The net effect is one of greater modularity, reliability, (because an object will not permit its data to be corrupted by inappropriate operations) and generally better understandability, due to the intuitive face objects present. "...modules may be functional (procedure-oriented) or declaritive (object- oriented)... we want modules that exihibit strong cohesion..." [2:p29] "A crucial property of an object is that its private memory can be manipulated only by its own operations." [1:p6] The second major indicator of "objectness" is the degree of modularity. Some try to argue that "C" is modular, simply because functions and data can be seperately compiled, but the language does not enforce any sort of binding within such modules! True objects will have tight binding, or cohesion, within a module, and loose coupling between other modules. This binding must extend to the binding between data and functionality, as stated in my first point. To sum up this too long answer: "We shall call this an *object-oriented* design methodology to emphasize the fact that it is not a purely functional design technique. Instead, this approach recognizes the importance of software objects as actors, each with its own set of applicable operations." [2:p40] References: [1] "Smalltalk-80, The Language and its Implementation", Adele Goldberg, David Robson [2] "Software Engineering With Ada", Grady Booch (excellent book!) -- :::::: Jan Steinman Box 1000, MS 61-161 (w)503/685-2843 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::