William Kent, "The State of Object Technology", Canadian Information Processing, July/August 1992. Also HPL-92-62, Hewlett-Packard Laboratories, April 1992. [4 pp]
William Kent
August 1992
> 1 INTRODUCTION . . . 1
> 2 COHERENCE AND ENCAPSULATION . . . 2
> 3 STRUCTURE AND BEHAVIOR . . . 3
> 4 DISPATCHING . . . 3
> 5 DIVERSIFIED ENVIRONMENT . . . 4
> 6 DIVERSITY OF SOLUTIONS . . . 5
> 7 CONCLUSIONS . . . 5
The one theme that uniformly characterizes the current state of object technology is diversity: of concepts, models, paradigms, viewpoints, applications, problems, solutions, and organizations. In trying to be all things to all people, it has become many things to many people. The fruit of object orientation is apples and oranges.
There isn't even consensus on the fundamental nature of what object orientation is. To some, a system is object-oriented if it provides discrete icons as objects at a graphical user interface. Some say that an object is a discrete unit of program code and data structure which provides a set of data processing services. To others, an object is an abstract entity represented in a computer system with only its external behavior exposed, its internal implementations being encapsulated out of sight. None of these are exactly the same concept.
While the metaphor of an object as an autonomous unit of behavior and state is appealing in its simplicity, it's too simple to be real. Sometimes an object does act autonomously and spontaneously, as you and I and computer programs often do. But sometimes an object is the passive object of activity, like an egg we break or a picture we paint or a document we edit. And sometimes behavior is a collective activity, like shaking hands or dancing or getting married or fighting or any team sport.
Some objects have a sense of physical coherence and spatial integrity, being all in one place like a data structure or a pie chart. Others are diffuse abstractions, like an engine design whose parts lists, design drawings, housing configurations, performance specifications, test data, cost analyses, and manufacturing plans might be widely scattered yet all the while remaining a single abstract concept: that particular engine design. Some are visible, like the pie chart, while others are invisible abstractions, like the engine design. Some things seem to be independent entities, like a book, while others are inextricably interlocked with others, like a wall whose inherent functionality is intertwined with other walls, floors, ceilings, windows, doors, and so on.
From the viewpoint of an object being something in a computational system representing an external concept or entity, a keystone of the object paradigm is an interface which supports user-visible behaviors while cleanly hiding implementations. Behaviors should remain stable over a variety of implementations which may change with time.
Object technology can thus be viewed from the diverse viewpoints of users and implementers, but we sometimes lose sight of the distinction. This is partly because the viewpoint may be relative to the object in question; method code which provides an implementation for one object may invoke operations as a user of other objects.
Various object models take it for granted that an object is coherent and localized in one or more of the following senses:
While it makes sense to define sets of objects having various combinations of these characteristics, none of these is true of all objects. Most of those concerns relate to the implementer's viewpoint, and should have little bearing on user-visible behavior. There are a few exceptions, such as the fact that Locate and Move operations make sense for some such objects, but not others. Also, dispatching might be explained differently in some of the above cases.
Correspondingly, there are two notions of encapsulation. In the narrow sense, objects are totally encapsulated from each other, having their programs and data disjoint from each other. In the broader sense, the object system as a whole provides an encapsulating interface which hides the implementations of all objects from users, without specifying how such implementations are organized.
There is also the related notion of object content. Some models assume that all objects have an intrinsic and well-defined content, such as the data in a file or the text in a document. Other models recognize that a document might exist as an object without text, e.g., during planning stages, or that its content might be any of several textual bodies (different versions or languages) and/or layout designs. What is considered intrinsic may depend on the user, and any of these contents should be retrievable by explicit operations.
Object technology embraces opposing views of data structure, making it richer yet less visible. Structural object orientation provides more complex data structures needed in such applications as engineering design and multimedia documents. Behavioral object orientation, on the other hand, encapsulates data structure as part of an object's hidden implementation, exposing only behavior in terms of operations on the objects. In the behavioral approach, for example, containment is not described in terms of the embedding of one data structure in another, but by the propagation of operations. Thus, when operations like Delete, Move, or Rotate are applied to one object, they automatically propagate to the "contained" object as well.
This dualism is reflected in dual approaches to object state. All agree that an object comprises both behavior and state. Most agree that whether data is stored or computed cannot be the distinguishing criterion from the user viewpoint, since different implementations might do one or the other for the same fact (the diameter might be stored as data for one circle, computed from a stored radius for another). However, the relationship between behavior and state is debated. One camp partitions object specifications into two distinct portions: behavior described in terms of operations and state described in terms of attributes and relationships. The other camp holds that such distinctions are arbitrary, since any operation might return a value and might alter the results of future requests. In the latter view, object state is characterized by specifying operations that alter the results of others; what needs to be remembered in order to effect this is a matter of implementation. Assigning a new diameter to a circle might be implemented as simply storing the new value, or as computing a new radius to be stored. In the behavioral view, attributes serve no essential purpose, being a legacy of the structural view of stored data.
The dualism is also reflected in a divergence of database interfaces. The traditional single interface between application logic and the data stored in a database is splitting into two levels. End users have a behavioral interface, invoking the operations defined in object interface specifications. Object definers implement such operations in terms of methods which access data at structural interfaces to databases. Behavioral and structural interfaces are separated by methods, with the behavioral interface supporting object users and structural interfaces supporting method implementers.
Object technology introduced diversity in the fundamental dispatching paradigm, the mechanism for initiating the execution of programs.
In the classical programming paradigm, a procedure invocation p(x) is intended to invoke a specific procedure p. Behaviors depending on the nature of the particular argument x are chosen within the procedure p. Programmers might provide alternative procedures p1 and p2, but it is then the user's responsibility to call p1(x) or p2(x) as appropriate. In either case, the system's job is simply to find and invoke the one specified procedure, which then manages the rest of the decisions.
This was revolutionized by the classical object-oriented paradigm. An object can have its own version of the procedure p, providing the specific behavior appropriate to itself. The system's job in this case is not to find the procedure, but to find the object x, which then initiates its own version of the procedure. The distinction is sometimes emphasized by a new syntactic form x.p, having the sense of a message p being sent to the object x. Other parameters could be sent along with the message in the form x.p(y).
Most object systems don't provide each object with its own version of the procedure p. Instead, objects of the same type could share a version. In effect, the system isn't really sending a message to the object to be interpreted by the object; the system is dispatching the appropriate version of p as determined by the type of the object x. This opens the way for the next generalization.
The generalized object-oriented paradigm allows the system to dispatch on the basis of more than one argument. For an invocation of the form p(x,y), the system might choose from multiple versions of p, each tailored to a particular kind of x and a particular kind of y.
As an example, suppose there are different techniques for printing different kinds of documents on different kinds of printers. In the classical model, a print request might be expressed as either a message doc1.print(prt1) to the document or a message prt1.print(doc1) to the printer. For the first message, the system dispatches a print procedure appropriate to the document, which then must select a printing technique for the specified printer. For the second message, the system dispatches a print procedure appropriate to the printer, which then must choose a printing technique for the specified document. In contrast under the generalized model, the system can handle a request of the form print(doc1,prt1), directly dispatching a procedure tailored to the specific document and printer.
It's interesting to observe that diversity and multiplicity also characterize the new information processing environment in which object technology is being applied. This may or may not be a coincidence, since object technology offers solutions to many of the problems in the new environment. The new environment includes diversity of:
Diversity of object concepts is more than richness. It is a problem. Software components built on fundamentally different premises, while all claiming to be object oriented, cannot work together. Ironically, there is even diversity in the solutions to the problem, and also in the organizations trying to solve the problem.
One style of reconciliation is to develop a unified super-model, in which each viewpoint can be found as a subset or restriction of the general model. The other approach is an interoperability framework in which distinct models can cooperate. Interoperability might be structured vertically, with one level of objects being implemented in terms of objects at a lower level (e.g., presentation objects, semantic objects, data processing objects). Interoperability can also be horizontal, via data interchange mechanisms.
Diverse agencies are addressing the problems of object technology. There are companies and consortia in the private sector, as well as government standards bodies, both in the United States and internationally. Some are concerned with the object paradigm in specific technologies, such as programming languages or databases, while others seek a uniform approach to object technology as a whole. The present author is active in two organizations addressing these issues. The Object Management Group (OMG) is an industrial consortium trying to reach rapid consensus on shared conventions to promote interoperability of applications using currently available technology. X3H7 (Object Information Management) is a new ANSI technical committee intended to foster harmony in the object-oriented aspects of various information processing standards.
Key steps in such reconciliation include:
We have an object-oriented elephant. Object technology is the sum total of all these views, but a coherent picture of the whole remains to be synthesized. This is the challenge currently facing such organizations as the Object Management Group and the new ANSI Technical Committee X3H7 (Object Information Management).