ArcGIS Engine Developer Guide

THE MICROSOFT COMPONENT OBJECT MODEL
Workspace-
Factory
Access-
Workspace-
Factory
Workspace
This is a simplified portion of the geodatabase
object model showing type inheritance among
abstract classes, coclasses, and instantiation of
classes.
IBirth
Interfaces
Classes
Human
IBirth
ITalk
IWalk
IDeath
ITalk
IWalk
Dog
IBirth
IWalk
IDeath
IDeath
IFly
Parrot
IBirth
ITalk
IWalk
IFly
IDeath
This diagram shows how common behavior,
expressed as interfaces, can be shared among
multiple objects, animals in this example, to
support polymorphism.
not a shortcoming since individual classes can implement multiple interfaces. See
the diagram to the lower left on polymorphic behavior.
Within ArcObjects are three types of classes that the developer must be aware of:
abstract classes, coclasses, and classes. An abstract class cannot be created; it is
solely a specification for instances of subclasses (through type inheritance).
ArcObjects Dataset and Geometry classes are examples of abstract classes. An
object of type Geometry cannot be created, but an object of type Polyline can.
This Polyline object, in turn, implements the interfaces defined within the Geometry
base class; hence, any interfaces defined within object-based classes are
accessible from the coclass.
A coclass is a publicly creatable class. In other words, it is possible for COM to
create an instance of that class and give the resultant object to the client to use
the services defined by the interfaces of that class. A class cannot be publicly
created, but objects of this class can be created by other objects within
ArcObjects and given to clients to use.
To the lower left is a diagram that illustrates the polymorphic behavior exhibited
in COM classes when implementing interfaces. Notice that both the Human and
Parrot classes implement the ITalk interface. The ITalk interface defines the
methods and properties, such as StartTalking, StopTalking, or Language, but clearly,
the two classes implement these differently.
INSIDE INTERFACES
COM interfaces are how COM objects communicate with each other. When
working with COM objects, the developer never works with the COM object
directly but gains access to the object via one of its interfaces. COM interfaces
are designed to be a grouping of logically related functions. The virtual functions
are called by the client and implemented by the server; in this way, an object’s
interfaces are the contract between the client and object. The client of an object
is holding an interface pointer to that object. This interface pointer is referred to
as an opaque pointer since the client cannot gain any knowledge of the implementation
details within an object nor direct access to an object’s state data. The
client must communicate through the member functions of the interface. This
allows COM to provide a binary standard through which all objects can effectively
communicate.
Interfaces allow developers to model functionality abstractly. Visual C++ developers
see interfaces as collections of pure virtual functions, while Visual Basic
developers see interfaces as collections of properties, functions, and subroutines.
The concept of the interface is fundamental in COM. The COM Specification
(Microsoft, 1995) emphasizes these four points when discussing COM interfaces:
• An interface is not a class. An interface cannot be instantiated by itself since it
carries no implementation.
• An interface is not an object. An interface is a related group of functions and
is the binary standard through which clients and objects communicate.
Chapter 4 • Developer environments • 61