Objectification

Objectification

[Edward Berard]

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

Re: Objectification

[Jerome_V_Vollborn]

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 

Re: Objectification

[Jerome_V_Vollborn]

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)
 

Re: Objectification

[Dick Dunn]

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.

Re: Objectification

[Edward Berard]

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

Re: Objectification

[Paul Scherf;685-2734;61-028;692-4142;orca]

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