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, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.lang.ada Subject: Objectification Keywords: object-oriented, distributed processing, persistence Message-ID: <534@ajpo.sei.cmu.edu> Date: 3 Aug 89 21:39:58 GMT List-Id: In September, there is going to be an informal workshop on "Ada Support for Object-Oriented Programming," hosted by your friends at MITRE. There will be a number of topics discussed. It is the intent of this message to cause some discussion on objectification, and its impact, if any, on possible extensions to Ada (i.e., extensions/revisions which will show up in Ada 9X). Objectification, as you will see, is an important issue for anyone who has chosen an object-oriented approach, and is interested in such things as distributed processing or persistent objects. First, we must define some terms. An object is a specific item, thing, or characteristic. Objects are black boxes which encapsulate: - knowledge of state - operations (and their corresponding methods) - other objects, i.e., you may have: - heterogeneous composite objects - homogeneous composite objects - exceptions - constants - concepts All interactions with an object take place through a well-defined interface. Those outside the object may either query or change the state of an object through the operations defined in the interface. Users of an object may use the constants, if any, provided in the interface of an object. An object may alert its environment of exceptional conditions through the exceptions, if any, advertised in the interface. [There are certain other aspects relating to "objects with life," i.e., objects which are capable of spontaneously changing their own state, which I choose not to cover at this time.] Since objects are black boxes, the underlying implementations of its operations (i.e., the corresponding methods), and the underlying implementation for the state of the object, are hidden from users of the object. In describing an object, we characterize it from an _external_ viewpoint. Further, we focus on the characteristics that the object has _in_ _isolation_, i.e., independent of any other object or application. Objects are instances of classes. A class is a template, pattern, or description of a category of very closely related items (i.e., objects). Classes themselves may be parameterized, in which case they are metaclasses. A metaclass is a class whose instances are themselves classes. A value is the unambiguously defined state for a given object. The state of an object is what we can know about the object from an external viewpoint. Values are themselves objects. The usual course of action in building object-oriented applications is to first create classes, and then to create objects which are instances of these classes. Once the objects are created they can be made to interact via some mechanism, e.g., message passing, as in Smalltalk. Let's say that you are planning to create a large object-oriented system in your favorite language. Everything proceeds nicely as long as all the objects, classes, and values remain in the main memory of one computer. However, things such as the following are bound to happen sooner or later in any real application: 1. You are developing a distributed processing application, and you wish to "transmit objects" from one node to another node. 2. You have a need for persistent objects. (Persistence is a measure of the volatility of the state of an object.) This means you may have to "store" and "retrieve" you objects from some place which is not main memory, e.g., a disk object. [Note: I find it interesting that the first item is typical of a concern mentioned by many "real-time" people, and that the second item is a concern often raised by people using an object-oriented approach for information systems (IS). Both of the above items, however, are not restricted to any particular application domain.] When attempting to "transmit objects" or "store and retrieve objects," software engineers often find that they must deal with hardware/software systems which only understand low-level, primitive objects and classes, e.g., characters, bytes, and bits. [A primitive object or class is an object or class whose definition is included in the definition of the environment, typically in the definition of the programming language. Primitive objects and class have two main uses: - They are used in the creation of user-defined (i.e., non-primitive) objects and classes. - They are use as a form of (low-level) communication among objects within a system of objects.] When attempting to "transmit an object" or to "store and retrieve an object," the software engineer must attempt to do something like the following: a. develop a mechanism for converting the the state of an object into something which is recognizable by the network, or by the storage device, e.g., reduce the state of an object to a collection of low-level, primitive objects, and b. develop a mechanism to retrieve, or re-constitute, objects from either the network or the storage device, e.g., recognize an object which is in the form of a collection of low-level, primitive objects, and re-create the object from these low-level items. "Objectification" is the process of taking some information, which is usually in the form of low-level, primitive objects, re-creating an object, and, quite possibly, also re-creating the corresponding class for the object. (It is the process described in "b" above.) The inverse of this process, i.e., "deobjectification," is usually thought of as a much simpler problem. (It is the process described in "a" above.) There are quite a few issues involved here, most of which I don't have time to discuss here, but here are a few to chew on: - Given a large distributed network, one scheme is to have knowledge of all classes on all nodes. This means, however, that you cannot "transmit" any objects to a node unless that node has knowledge of the class of that object. - One way to solve the above problem is to define a mechanism for transmitting classes among the nodes of a network. However, this creates a new question, i.e., what is meant by "transmitting a class," and how might this be accomplished? - There are, of course, all the advantages and problems associated with having "the same" objects, classes, and values on several different nodes on a network, e.g., indeterminism, and "what happens if something gets clobbered during the transmission process?" - What is the best way to recognize a specific object or class when it is being received at a node? What are the more reliable and efficient mechanisms for objectifying this incoming information? - How should I store objects? Do I store only the state information? Do I also store class information? If I choose not to use an object-oriented DBMS (OODBMS), what are the tradeoffs? If I choose to use a OODBMS, what issues must I now address? - After I have stored an object, suppose I wish to: - change the object's state without first removing it from storage - change the definition for the class of the object Are either of the above advisable? If so, how would I accomplish them? - Should I allow only one class of object to be stored and retrieved in the same object store? If I allow multiple classes, what are the implications? - Considering that objects can be composed of other objects, and those objects, in turn, can be composed of still other objects, what affect does this have on objectification? These, and other objectification issues, are not unique to any particular programming language. (See, for example, the current discussions on comp.lang.c++.) A number of interesting problems and solutions have already been discussed elsewhere, but this is an issue we must address if we want to use an object-oriented approach for many real applications. -- Ed Berard Berard Software Engineering, Inc. 18620 Mateney Road Germantown, Maryland 20874 Phone: (301) 353-9652 E-Mail: eberard@ajpo.sei.cmu.edu