eberard@ajpo.sei.cmu.edu (Edward Berard) (08/04/89)
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.eduJerome_V_Vollborn@cup.portal.com (08/05/89)
Part of Ed's article has to do with the environment that objects live in. Let me propose my ideal environment and then note some problems in building that environment. The physical world environment is a large manufacturing company where parts are produced in both domestic and foreign (European and Middle Eastern) plants and assembled into finished products in the Pacific Rim countries. All of these plants are currently connected by a wide area network. The top level object is a shippable part. Component parts are subobjects. The production plants, production equipment and materials are also objects. Each of these software objects that model the real world objects exist in an enterprize wide object space. The production objects (and under special cases production equipment objects) move through the production process and then cease to exist when they
Jerome_V_Vollborn@cup.portal.com (08/05/89)
Please pardon the previous, incomplete article. I pressed the wrong key when I got to the end of the first page. Ed's article about object oriented environments opens the question of the ideal environment for object oriented systems. Let me describe my ideal environment and then describe some problems achieving that environment. The physical setting is a large manufacturing company where component parts are built in domestic and foreign (European and Middle Eastern) plants and assembled into shippable products in Pacific Rim countries. All of the plants are connected by a wide area network and have local area networks connecting production equipment to controllers within the plants. In the software model of this company, the top level object is a shippable product. The shippable product is composed of objects represnting parts. The production plants, production equipment and materials are also objects. The part objects come into existance as raw material and acquire attributes as they move through the plants. The production equipment adds or measures attributes of the part objects. Combining part objects into larger parts or shippable products is accomplished by establishing relationships between part objects and the larger object. When a shippable product object goes to shipping and thence out the door, it ceases to exist. Notice that objects need to move inside plants and between plants. These movements must be verified (at least below the surface of the object environment). Object integrity must be verified. Errors must be detected and prevented from propagating to other objects (or outside some local environment section). Some method of recovering from environment errors and discontinuities must be provided. Implementing the environment using today's major operating systems is a non-trivial task. The first problem is to provide an object environment on a node. This would seem to be a fairly heavy layer (messaging, object creation, object deletion, object behavior monitoring, object check pointing, ... ) on top of current operating systems (especially if you insist on an efficient implementation). Building a single node system would probably be misleading at best since the assumptions built into a single node implementation would make extension to multiple node systems very difficult if not prohibitively expensive. Finding the right people to implement the first such system would also be a large problem. Very few software engineers (and almost no programmers) are able to think in terms of concurrent objects. Most of those who can think in those terms are very highly paid (some also have trouble working with other such people (ego problems mainly ;-). The other people problem is convincing mangers with budget authority to embark on such a "risky" project that will encroach on fiefdoms like MIS. I think the technical problems can be solved using object oriented techniques. Using functional decomposition will result in an expensive failure IMHO. Solving the people problems is perhaps impossible, certainly very difficult. Building pieces of such a system will leave software engineers (at least me) feeling like kids looking in the window of a candy store. Jerome Vollborn (Jerome_V_Vollborn@cup.portal.com or uunet!lci386!jerome)
rcd@ico.ISC.COM (Dick Dunn) (08/08/89)
eberard@ajpo.sei.cmu.edu (Edward Berard) writes about many matters and
meta-matters roughly related to OOP and moving toward it. All well, but
couldn't someone come up with a better word (or perhaps I should just say
"a word") for the concept? "Objectification" is sufficiently ugly and
silly-sounding (sounds like it came out of a congressional committee) to be
an impediment to the goals.
--
Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...Simpler is better.eberard@ajpo.sei.cmu.edu (Edward Berard) (08/08/89)
In article <15991@vail.ICO.ISC.COM>, rcd@ico.ISC.COM (Dick Dunn) writes: > eberard@ajpo.sei.cmu.edu (Edward Berard) writes about many matters and > meta-matters roughly related to OOP and moving toward it. All well, but > couldn't someone come up with a better word (or perhaps I should just say > "a word") for the concept? "Objectification" is sufficiently ugly and > silly-sounding (sounds like it came out of a congressional committee) to be > an impediment to the goals. > ...Simpler is better. I very much agree that simpler is better. However, the discussion on "objectification" has been going on for some time now, and that is the term that people are using. For example, consider the following discussion which appeared on comp.lang.c++: --------------------------------- Subject: Re: Objectifying incoming messages? ^^^^^^^^^^^^ From: raph@tigger.planet.bt.co.uk (Raphael Mankin @ RT5111, BTRL, Martlesham Heath, England) (45 lines) More? [ynq] davidm@cimshop.UUCP (David Masterson) writes: >I'm working in an area doing C++ development that has several processes >communicating with one another. The messages shipped back and forth tend to >be asynchronous, so a receiving process cannot know what the message is or who >it came from until it looks at the message data. My question is this: >What is the appropriate method of taking a generic object (Message) and >turning it into an object of the type that is embedded in the message (say, >Employee)? Should this be done through virtual functions and subclassing of >the Message object? Or is it more appropriate to have the Message object look >at itself and construct an object of the appropriate type (perhaps some sort >of array of pointers to object constructors)? >The fundamental question hinges around the lack of context of the incoming >message. Therefore, the message user must look at the data in order to >determine what to coerce (definition?) the message into. Is this appropriate >or is there a better way? This is a fundamental problem of strongly typed languages. Ada pretends that it is not there but really has a worse problem than C++. Suppose you have a file with many variant records (unions) in it. You cannot allocate buffer space for the record until you know what type it is, and you cannot know what type it is until you have allocated space and read the record in. Ada does not permit you to read into a char* or (void*) and then cast the data when you have examined the non-variant header. The only way I have found of doing this in C++ is to go back to the old fashioned way of using a switch with a different cast in each branch. This is messy verbose and generally nasty. The only satisfactory solution is to allow types to be first-class objects so that we could have 'variable' casts. e.g. Type t = typelist[discriminant]; return (t)record_area; The run-time costs of this are horrible and I am not really suggesting it as a solution in C++. Does anyone have a sensible solution? Raphael Mankin raph@planet.bt.co.uk ---------------------------------- You will find discussions which use the terms "objectify," "deobjectify," "objectification," and "deobjectification" in a number of places. Typically, you will find them coupled with discussions of persistence, disk accessing, and OODBMS. By the way, a number of interesting solutions have also been proposed. -- Ed Berard (301) 353-9652
paulsc@radio_flyer.WV.TEK.COM (Paul Scherf;685-2734;61-028;692-4142;orca) (08/08/89)
In article <15991@vail.ICO.ISC.COM>, rcd@ico.ISC.COM (Dick Dunn) writes: > eberard@ajpo.sei.cmu.edu (Edward Berard) writes about many matters and > meta-matters roughly related to OOP and moving toward it. All well, but > couldn't someone come up with a better word (or perhaps I should just say > "a word") for the concept? "Objectification" is sufficiently ugly and > silly-sounding (sounds like it came out of a congressional committee) to be > an impediment to the goals. I've read several articles mentioning "Objectification", before I figured out what "Objectification" was. I liked the terms "activation" (reading in an object) and "passivation" (writing out an object, so that it may be activated at a later time), used by Brad Cox in his book. Paul Scherf, Tektronix, Box 1000, MS 61-028, Wilsonville, OR, USA paulsc@orca.WV.Tek.com 503-685-2734 tektronix!orca!paulsc