ArcGIS Engine Developer Guide

THE MICROSOFT COMPONENT OBJECT MODEL
ESRI chose COM as the component technology
for ArcGIS because it is a mature technology that
offers good performance, many of today’s
development tools support it, and there is a
multitude of third-party components that can be
used to extend the functionality of ArcObjects.
The key to the success of components is that
they implement, in a practical way, many of the
object-oriented principles now commonly
accepted in software engineering. Components
facilitate software reuse because they are selfcontained
building blocks that can easily be
assembled into larger systems.
Before discussing COM specifically, it is worth considering the wider use of software
components in general. There are a number of factors driving the motivation
behind software components, but the principal one is the fact that software development
is a costly and time-consuming venture.
In an ideal world, it would be possible to write a piece of code once and reuse it
again and again using a variety of development tools, even in circumstances that
the original developer did not foresee. Ideally, changes to the code’s functionality
made by the original developer could be deployed without requiring existing users
to change or recompile their code.
Early attempts at producing reusable chunks of code revolved around the creation
of class libraries, usually developed in C++. These early attempts suffered from
several limitations, notably difficulty of sharing parts of the system (it is difficult to
share binary C++ components—most attempts have only shared source code),
problems of persistence and updating C++ components without recompiling, lack
of good modeling languages and tools, and proprietary interfaces and customization
tools.
To counteract these and other problems, many software engineers have adopted
component-based approaches to system development. A software component is a
binary unit of reusable code.
Several different but overlapping standards have emerged for developing and
sharing components. For building interactive desktop applications, Microsoft’s
COM is the de facto standard. On the Internet, JavaBeans is viable technology. At
a coarser grain appropriate for application-level interoperability, the Object
Management Group (OMG) has specified the common object request broker
architecture (CORBA).
To understand COM—and, therefore, all COM-based technologies—it’s important
to realize that it isn’t an object-oriented language but a protocol, or standard.
COM is more than just a technology; it is a methodology of software development.
COM defines a protocol that connects one software component, or module,
with another. By making use of this protocol, it’s possible to build reusable
software components that can be dynamically interchanged in a distributed
system.
COM also defines a programming model known as interface-based programming.
Objects encapsulate the manipulation methods and the data that characterizes each
instantiated object behind a well-defined interface. This promotes structured and
safe system development since the client of an object is protected from knowing any
details of how a particular method is implemented. COM doesn’t specify how an
application should be structured. As an application programmer working with
COM, language, structure, and implementation details are left up to you.
COM does specify an object model and programming requirements that enable
COM objects to interact with other COM objects. These objects can be within a
single process, in other processes, or even on remote machines. They can be
written in other languages and may have been developed in different ways. That
is why COM is referred to as a binary specification or standard—it is a standard
that applies after a program has been translated to binary machine code.
58 • ArcGIS Engine Developer Guide