Editor's Note: There is currently a great deal of overlap among thevarious subsections of this section (i.e., the subsections describing "operations","requests", "messages", "events", and soon). This will need to be dealt with as further glossary work is done,and further analysis of the Features Matrix entries takes place.
OODBTG Reference Model
See entry under 2.1 operations
OMG Core Object Model
See entry under 2.1 operations
OMG CORBA IDL
An object is an identifiable, encapsulated entity that provides oneor more services that can be requested by a client [CORBA Specification2.2.1 Objects].
ODMG
Objects are instances of a type, and as such have state, behavior andidentity. All objects are of type Denotable_Object. An object can be mutable(instance of type "object") or immutable (instance of type "literal").The remainder of this note will use the term object to refer to mutableobjects.
Objects and literals can be atomic or structured. The identity of objectsis represented by OIDs; typically literals are identified by their value.Objects may also have meaningful name(s) in addition to identity (propertiesof objects include "has_name?" and "names").
EXPRESS
An EXPRESS Entity type represents a class of real-world objects whichshare common properties. The instances of this data type then individuallyrepresent these real-world objects.
Management Information Model
A managed object is an abstraction of a physical or logical entityfor the purpose of management. It contains the specific information associatedwith the management of that physical or logical entity.
A managed object class defines the characteristics of a typeof physical or logical resource. Instances of a managed object class existto represent specific instances of a resource. Therefore, a managed objectis an instance of a managed object class. The terms "object"and "object instance" are synonymous.
SQL3
One of the basic ideas behind the object extensions in SQL3 is that,in addition to the normal built-in types defined by SQL, user-defined typesmay also be defined. These types may be used in the same way as built-intypes. For example, columns in relational tables may be defined as takingvalues of user-defined types, as well as built-in types. A user-definedabstract data type (ADT) definition encapsulates attributes andoperations in a single entity. In SQL3, an abstract data type (ADT) isdefined by specifying a set of declarations of the stored attributes thatrepresent the value of the ADT, the operations that define the equalityand ordering relationships of the ADT, and the operations that define thebehavior (and any virtual attributes) of the ADT. Operations are implementedby procedures called routines. ADTs can also be defined as subtypesof other ADTs. A subtype inherits the structure and behavior of its supertypes(multiple inheritance is supported). Instances of ADTs can be persistentlystored in the database only by storing them in columns of tables.
A row type is a sequence of field name/data type pairs resemblinga table definition. Two rows are type-equivalent if both have the samenumber of fields and every pair of fields in the same position have compatibletypes. The row type provides a data type that can represent the types ofrows in tables, so that complete rows can be stored in variables, passedas arguments to routines, and returned as return values from function invocations.This facility also allows columns in tables to contain row values. A namedrow type is a row type with a name assigned to it. A named row typeis effectively a user-defined data type with a non-encapsulated internalstructure (consisting of its fields). A named row type can be used to specifythe types of rows in table definitions. A named row type can also be usedto define a reference type. A value of the reference type definedfor a specific row type is a unique value which identifies a specific instanceof the row type within some (top level) database table. A reference typevalue can be stored in one table and used as a direct reference ("pointer")to a specific row in another table, just as an object identifier in otherobject models allows one object to directly reference another object. Thesame reference type value can be stored in multiple rows, thus allowingthe referenced row to be "shared" by those rows.
Tables have also been enhanced with a subtable facility. A tablecan be declared as a subtable of one or more supertables (it is then adirect subtable of these supertables), using an UNDER clause associatedwith the table definition. When a subtable is defined, the subtable inheritsevery column from its supertables, and may also define columns of its own.The subtable facility is completely independent from the ADT subtype facility.
See also 7. Types and Classes, and 8. Inheritance and Delegation.
Matisse
In April, 1993, at a public meeting of experts in object technologystandards and SQL3 language development, the following tenets were proposedas fundamental to the object paradigm. [5]
T1. A first class object has unique, immutable identity within its scopein a distributed environment.
This is essential for pointer navigation in a database, for maintenanceof the referential integrity of the database without a lot of extra overheaddoing special checking, for allowing multiple unique objects with the sameattribute values, and for many important analysis and design considerations.Khoshafian et al. [6] outline the many technical advantages of object identity.
T.2. A first class object always knows what type(s) it is.
Several problems are associated with an object not knowing what typeit is. For example, if persistent objects lose knowledge of their typewhen read from the database into memory, this affects the association ofproper behavior with the object.
T.3 A instance of a subtype is always an instance of its supertype.
This is a major feature in most commercial object-oriented productsbecause it allows type safe utilization of supertype instances anywherein a program where the subtype is expected.
T.4. First class links occur only between first class objects.
Support of inverse links on first class links guarantees the referentialintegrity of a database without the additional overhead of stored procedures.
The Matisse Object Model supports these fundamental tenets with thecaveat that Matisse objects can only be of one type. All Matisse objectsare first class objects including instances, class schemas, and the Matissemetamodel (all are stored as objects in the database).
The structure and behavior of Matisse objects flows from the Matissemetamodel. The user can modify the metamodel, which changes the Matisseobject model. The metamodel is a template for creation of the class schema.Class schema objects are, in turn, templates for creation of instancesof a class.
Matisse is a completely versioned database supporting copy semantics.A change to an object always results in creation of a new version of theobject without altering previous versions or the object identifier (OID)of the object. Versioning is orthogonal to object model considerationsand is handled transparently by the Matisse Server Engine.
C++
In C++, an object is a region of storage with associated semantics.The declaration int i;, specifies that iis an object of type int. In the context ofthe object model of C++, the term object refers to an instance ofa class. Thus a class defines the behavior of possibly many objects (instances).Objects are usually referred to by references, which are aliasesfor an object. "The obvious implementation of a reference is as a(constant) pointer that is dereferenced each time it is used." [Str92]
A C++ class definition generates a user-defined type. A class definesthe characteristics of its instances in terms of members: data members(state) and member functions (methods or operations), and the visibilityof these members to other classes. The class defines the form of all objectsthat belong to that class. Each object of the class that is created getsa copy of all the class data members, except for those declared as static(see entry under 2.6 state). All objects of a particular class sharethe member functions for that class.
OOCOBOL
An object is a single entity comprising data and methods. An objectbelongs to a class. A class describes the structure of the data and themethods that apply to all the objects belonging to that class. A classalso has a single class object with data and methods. The class objectis an object that acts as a creator of objects.
Each object has an interface comprising the names and parameter specificationsfor each method supported by the object. Each class defines two interfaces:an interface defining the methods supported by the class object (the classobject interface), and the interface to be supported by each instance ofthe class.
Interfaces independent of class objects or class instances may be definedby listing the method names and parameter specifications supported by thoseinterfaces. Such an interface may be specified in the declaration of anobject identifier to restrict the objects that may be referred to by thatidentifier to objects whose interfaces conform to the specified interface.Conformance is a relationship between interfaces. One interfaceis said to conform to a second interface if an object that implements allthe methods specified in the first interface may be used anywhere an objectthat implements all the methods specified in the second interface may beused. A formal definition for conformance is included in the specifications[Obi94].
See also entry under 7. Types and Classes.
Editor's Note: The concept of conformance in OO COBOL resembles thatin the Emerald language.
Smalltalk
An object is an encapsulated software component made up of memory andoperations that creates a coherent programming entity. All objects arean instance of a class. Everything in Smalltalk is an object-from numbersto entire applications. Objects have public and private properties. Anobject's implementation details are private and are hidden from other objects.An object's public properties are its messages that make up its interface.The object's private properties are its variables. Interaction with anobject only occurs via these messages to its interface. All object instancesof a given class have a common message interface.
Eiffel
Objects in Eiffel are instances of an abstract data type. The propertiesof abstract data types are described in a class.
An abstract data type separates the implementation of a class from the`public interface'. The public interface details the ways an object canbe manipulated through operations. There may be more than one public interfacefor a particular Eiffel class. The interface depends on the type of theobject requesting a particular operation. For example, an operation `op'may be public to class `A' but not to class `B'. See also entry under 5.Encapsulation.
Objects have an immutable identity that exists for the lifetime of theobject. The identity of all objects in an Eiffel program are unique.
Objects have unique state (i.e., the data for each object is unique).Objects of the same type share the same implementation. It is also possiblefor objects to share particular state entities among all instance of theirtype.
Entities may be either references to objects (called a reference type)or may be actual objects themselves (called expanded types). See also entryunder 9.4 Containment.
Emerald
Each Emerald object has four components:
1. A name, which uniquely identifies the object within a distributednetwork
2. A representation, which consists of the data stored in theobject. The representation of a programmer-defined object is composed ofa collection of references to other objects.
3. A set of operations, which define the functions and proceduresthat the object can execute. Some operations are exported and may be invokedby other objects; others are private and may only be invoked by the containingobject.
4. An optional process, which operates in parallel with invocationsof the object's operations. An object with a process is active andexecutes independently of other objects. An object without a process ispassive and executes only as a result of invocations.
An Emerald object also has several attributes. An object has a locationthat specifies the node on which the object is currently resident. Emeraldobjects can be defined to be immutable; this simplifies sharingin a distributed system, since immutable objects can be freely copied.Immutability is an assertion by the programmer that the abstract stateof an object does not change; it is not a concrete property, and the systemdoes not attempt to check it. [BHJL86]
See entry under 2.9 communication model for an example objectdefinition.
SELF
SELF objects consist of named slots, each of which contains areference to some other object. Some slots may be designated as parentslots by appending asterisks to their names (objects may have multipleparents, thus supporting multiple inheritance) [CUL89]. Objects may alsohave SELF code associated with them by having slots contain referencesto method objects containing the code.
When a message is sent to an object (called the receiver of themessage), the object is searched for a slot with the same name as the message.If a matching slot is not found, the contents of the object's parent slotsare searched recursively, using built-in multiple inheritance rules todisambiguate any duplicate matching slots. [This search is similar to thatwhich takes place in a class-based system during dispatching, except thatin SELF the objects being searched are instances representing applicationentities, rather than class objects representing descriptions of otherobjects.] Once a matching slot is found, its contents are evaluated andthe result is returned as the result of the message send. An object accessesits own state (slots) by sending messages to "self" (the receiverof the current message).
A non-code object evaluates to itself (and so the slot holding it actslike a variable). A method object is a prototype activation record. Whenevaluated, the method object clones itself, fills in its selfslot with the receiver of the original message, fills in its argument slots(if any) with the arguments of the message, and executes its code. Theself slot is a parentslot so that the cloned activation record inherits from the receiver ofthe original message. [US87]
SELF supports assignment to data slots by associating an assignmentslot with each assignable data slot. The assignment slot contains theassignment primitive object (effectively a method). When the assignmentprimitive is evaluated as the result of a message send, it stores its argumentinto the associated data slot. A data slot with no corresponding assignmentslot is a constant or read-only slot, since a running program cannot changeits value. For example, most parent slots are constant slots. However,a parent slot can be made assignable by defining a corresponding assignmentslot. An assignable parent slot permits an object's inheritance to be changeddynamically. [CUL89] See entry under 2.6 state.
System Object Model (SOM)
SOM objects are derived from a root object which defines the essentialbehavior common to all SOM objects. Factory methods are used to createSOM objects at run time. These factory methods are invoked on a class object,in the SOM run-time.
OLE Component Object Model
The Component Object Model specifies a programming-language-independentbinary standard for object implementations (i.e., it specifies whatthe implementation of the objects has to look like). Any object conformingto this standard is a legitimate Windows Object, no matter what languageis used to implement it.
Users of objects always obtain and act through pointers to object interfaces.An implementation of an interface is an array of pointers to functions(the functions themselves are implemented by the object). Any code thathas a pointer to that array can call the functions in that interface. AWindows Object implements one or more interfaces, i.e., provides pointersto function tables for each supported interface. Users never obtain pointersto an entire object. For example, when the user of some object first obtainsa pointer to the object, the user actually gets a pointer to one of theobject's interfaces. This pointer allows the user to call only the functionsin that one interface's function table. Through this pointer, the userhas no access to any state of the object, nor does the user have any directaccess to functions in other interfaces.
A Windows Object is any object, in whatever form, that supports at leastone predefined interface, called IUnknown. As part of the IUnknowninterface, OLE defines a standard function, called QueryInterface,through which the user of one interface of an object can obtain a pointerto another interface of the same object. QueryInterface takes asinput a pointer to an interface identifier (IID) for the desired interface,and either returns an error (and a NULL pointer), meaning the object doesnot support the interface, or a valid pointer to the new interface. [Seeentry under 6. Identity, Equality, Copy for a discussion of IIDs.]All other interfaces in OLE are derived from IUnknown, so all interfacescontain the QueryInterface function (the other two functions ofIUnknown are AddRef and Release). This insures thatnavigation is always possible between the interfaces of a given object.
A Windows Object must be able to provide a separate function table foreach interface it supports. The implementation of the IUnknown functionsin each supported interface must be "aware" of the entire object,because they must be able to access all other interfaces in the objectand must be able to affect the object's reference count.
The implementation in the component object library (COMPOBJ.DLL) providesa small number of fundamental API functions that permit creation of whatis called a Component Object, a special type of Windows Object identifiedwith a unique class identifier that associates an object with a particularDLL or EXE in the file system. A Windows Object does not always need tobe structured as a Component Object such that the API functions in COMPOBJ.DLLcan create it. Use of such API functions is merely one way through whichan initial pointer to an object can be obtained.
Unlike C++, where objects are defined using class definitions whichgenerate user-defined types, Windows Objects are defined in terms of theinterfaces they support. Since all objects support at least one interface(IUnknown), all Windows Objects are at least of type IUnknown,and can be treated as being of another type by using a different interface.Because of this mechanism, there is no single user-defined type associatedwith a Windows Object class, as there is with a C++ class. In fact, thereis no specific way to identify a specific object. This is because objectreferences (pointers) in Windows Objects are not references to the objectitself, as in C++, but rather are pointers to one of the object's interfaces.Given a pointer to an interface, the user can access only functions containedin that interface. The user can never have a pointer to the whole object(because there is no direct user-visible concept of "whole object"),so there is no direct access to state, and no concept of "friend"as in C++. Through the IUnknown interface, a user can obtain pointersto other interfaces that the object also supports, but this means obtaininga different pointer that refers (indirectly) to the same object.Each pointer to an interface points to a function table associated withthe object, and each table contains only functions for a specific interface.Because a pointer to a Windows Object always points to a function table,such a pointer can also be used from within programs written in languagesother than C++, such as C or assembly code.
The list of interfaces that an object of a specific class supports isconstant only within a specific object's lifetime, and can vary betweendifferent instances of objects of the same class. It cannot be assumedthat if Object 1 of class X supports a particular set of interfaces, Object2 of class X does as well. (Note that the "class" denotes theapplication providing the object's implementation, not the set of interfaces(type) supported). It also cannot be assumed that if objects of class Xonce supported interface Y, they always will, because the object mightchange later. This provides justification for the QueryInterfacemechanism of dynamically finding out about interfaces. It is always possibleto find out about other interfaces the object supports; thus, if an objectis acquired as an instance of a "superclass", it is possibleto find out what specific "subclass" it is by examining the otherinterfaces at runtime. There is no requirement to always treat an objectas an instance of the type (interface) through which it was originallyacquired.
Analysis and Design Methods
SA: "Definition: An object is anabstraction of a set of real-world things: such that:
'Object' is used in two senses: 1. atypical unspecified instance 2. the class of all instances.
CA: "An abstraction of somethingin the domain of a problem or its implementation, reflecting the capabilitiesof a system to keep information about it, interact with it, or both; anencapsulation of Attribute values and their exclusive Services. (Synonym:an Instance.)"
RA: "A discrete, distinguishableentity which quantizes data." "A concept, abstraction, or thingwith crisp boundaries and meaning for the problem at large." Instance.
JA: "An object is characterizedby a number of operations and a state which remembers the effect of theseoperations." Instance
WD: "The primitive element of object-orientedprogramming is an object. ... an object retains certain information, andknows how to perform certain operations." Instance.
MD: An object is a data structure ofa specified abstract data type. "...a class is a type, an object isan instance of a type. ...an object is a purely dynamic concept, whichbelongs not to the program text, but to the memory of the computer, whereobjects occupy some space at run-time once they [have] been created..."
EA: "An object is a person, place,or thing. An object may be physical or conceptual."
FA: "An object corresponds to aconcept, abstraction, or thing that can be distinctly identified. Duringanalysis, objects have attributes and may be involved in relationshipswith other objects. [The authors do not maintain a distinction between'thing of interest' and 'abstraction representing thing.'] "The readershould note that the notion of object during analysis is different fromthat usually employed. Many methods permit analysis objects to exhibitdynamic behavior and have a method interface; this is not the case in [thismethod], where analysis object have no interface and no dynamic behavior."
FD: "During design, the notion ofobject is extended by the introduction of methods and object attributes."
FC: "In the implementation phasethe notion of object is determined by the programming language."
OA: "An object is anything to whicha concept applies. It is an instance of a concept." 'Object' is usedboth for the model of a thing and for the thing itself.
BD: "An object has state, behavior,and identity; the structure and behavior of similar objects are definedin their common class; the terms instance and object are interchangeable."
'Object' is used both for the model ofa thing and for the thing itself.
"...[S]ome things ... are distinctlynot objects. For example, [some] attributes ... On the other hand, thesethings are all potentially properties of other objects."
HA: "An object is a particular instanceof a class".
NA: An object is an instance of a class"built according to the description in [the] class." 
features matrixintro page