* Further Thoughts on Moving Objects
@ 1989-09-04 15:36 Edward Berard
0 siblings, 0 replies; only message in thread
From: Edward Berard @ 1989-09-04 15:36 UTC (permalink / raw)
First, let me state some general observations:
- Many of the problems associated with "object movement,"
e.g., deobjectification (i.e., the decomposing of a "large"
or "complex" object into smaller, more primitive objects)
and objectification (i.e., the "re-constitution" of a large
object from smaller, more primitive objects), are identical
to those problems faced when attempting to store objects in
non-object-oriented database management systems
(non-OODBMSs). More specifically, there is a class of
problems which arise when objects (and classes) must be
given to and/or retrieved from an interface which does not
recognize "large" or "complex" objects, or, for that matter,
objects in general.
- Well-designed objects and classes are designed "in
isolation," i.e., apart from any specific application. While
the designer of the object or class may know about the
underlying implementation of the object or class, he or she
should avoid attempting to "tune" the object or class for
any specific application. (This not only enhances
reusability, but also often has a positive impact on
reliability.)
- Well-designed objects and classes provide the necessary
items (e.g., operations, constants, and exceptions) in their
interfaces (specifications) to accomplish any necessary work
involving the object or class. Note that since well-designed
objects and classes ordinarily provide only simple
(primitive) items in their interfaces, a specific task may
require (possibly complex) combinations of these simple
items.
Suppose, for whatever reason, I wish to move an object (or class) from
one node on a network to another node. What kinds of situations might
I find? The trivial case is one where the object is itself a simple or
primitive object which is recognized by the interface (i.e., the
communication link), and no transformation is necessary.
If the object is not a composite object (i.e., from an external
viewpoint, the object is not (conceptually) composed of other
objects), there may be operations in its interface which will return
the state of the object in the form of primitive objects which are
recognizable by the communication link. There are, however, special
problems which can arise, e.g.:
- The object is conceptually not a composite object, but its
implementation involves (possibly complex) combinations of
objects. In some cases the goal of information hiding may
actually prevent the object from being efficiently
"deobjectified."
Consider a "post office object." Suppose that the interface
for such an object contains only the following operations:
- is_there_any_mail (for a given address)
- send (this mail)
- pick_up_mail (for a given address)
From the outside, the post office appears to be a single,
monolithic object. However, suppose that the designer of the
post office included such items as mailboxes, collections of
mailboxes, and clerks in the underlying implementation of
the post office? How would one represent the state of such
an object so that it could be moved (from one node in a
network to another)? One possible answer is that through
successive invocations of the "pick_up_mail" operation, one
could remove all the mail from a post office on one node,
deobjectify this mail, transmit the deobjectified mail over
the network, objectify the mail at the receiving node, and
through successive invocations of the "send (this mail)"
operation on an "empty" post office, create a copy of the
original post office.
- If the object is an "object with life" (i.e., an object
which is capable of spontaneously changing its own state),
the internal state of the object may be constantly (and
rapidly) changing. How does one effectively capture and
transmit this state? Consider an air traffic control (ATC)
application. An "airplane" is a classic object with life.
How does one transmit an airplane object from one node to
another?
There are other questions and issues (e.g., the non-determinism
inherent in having two copies of the "same" object on two different
nodes). There are also quite a number of possible solutions. Since
object movement may not be something which can be avoided completely,
its ramifications should be considered in both object and system
design.
-- Ed Berard
(301) 353-9652
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~1989-09-04 15:36 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-09-04 15:36 Further Thoughts on Moving Objects Edward Berard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox