Multiple Interfaces
March 20, 2000
Objects actually define multiple interfaces
depending on their complexity.
But this should not be hard to understand.
Most objects can do many different things.
Consider the human being in terms of a programming
object.
Humans are very flexible in terms of their capabilities.
They can, amongst other things, move as well as sense
their surroundings. Within the first category, the object
may have methods such as walk, run and crawl.
Within the second category, senses, we may choose to include
such things as hearing, seeing, tasting and touching.
While it is therefore true to say that the entire
interface of the [ simplified ] human object is
walking, running, crawling, hearing, seeing, tasting, and touching,
COM developers tend instead to describe their objects in
terms of functionally related methods instead, although
this division is not mandatory.
The human COM object, therefore, would be more likely
described as implementing 2 interfaces, the movement
interface and the sensing interface. Each interface
would then contain a list of its related functions.
Of course it is the ubiquitous IDL that is going to
provide the interface descriptions.
Of course, although any object can have multiple interfaces, they
must have at least one.
Each and every COM object that you write implements the
IUnknown interface by default, (you do not need to do anything
to ensure this). It is the IUnknown interface that provides
the absolute minimum functionality that every COM object is
going to require, regardless of the methods/properties that
you provide via the custom interfaces that you implement.
The methods of the IUnknown interface deal with such things
as reference counting for the object, so as to ensure it is
garbage collected at the appropriate time. It is also via the
IUnknown interface that the object can be queried regarding
the other interfaces that it implements, and therefore
about its capabilities.
COM objects that are going to be used by languages
without strict data typing [ such as VBScript, Perl,
and Javascript ], also implement the IDispatch interface.
A detailed discussion of the functionality and internals
of the IUnknown and IDispatch interfaces is really beyond
the scope of this article, as it would lead very quickly
into the detailed internals of COM. But you should at least
get familiar with the names.
|
COM components run in the context of Microsoft's COM runtime.
It is the COM runtime that is responsible, transparently, for
making sure that method calls reach the proper objects and
methods within a COM object, and that the results of these
calls are returned to the calling application as expected.
The objects that comprise the COM runtime, and do all this work
behind the scenes are packaged in a number of Dynamic Link
Libraries [DLLs], that are installed on the system.
In the context of Perl, the PDK is this development
environment that is going to take your Perl components,
and describe them in a COM compliant manner - in effect,
wrapping your Perl object in a COM IDL wrapper.
So where do you obtain the PDK? How do you install the PDK?
How do you use the PDK? All these questions will be answered
in good time. But first, we have not completed our whistle
stop tour of COM.
|
The IDL
Introduction to Perl on Windows - Table of Contents
How does the IDL describe my object?
|
