The IDL
March 20, 2000
Ask a seasoned COM developer what concept is at the
heart of COM's egalitarian society, and the response will
probably be something to the effect of "COM depends on
interfaces".
An interface provides a detailed contract that specifies
exactly how the objects should be allowed to communicate.
So why go through the trouble of writing a contract for
every object in your program?!?
Well, the interface provides a protective layer that
sits between objects.
As such, an interface assures both parties that no matter
how each object changes internally, that the two objects
will always be able to communicate because they will always
implement the interface in exactly the same way.
In other words, implementation is entirely opaque to those
who use the object - and this is exactly the way that it
should be. Not only do I now\t want to spend time
understanding how object X implemented its functionality,
but if object X changes that implementation, it should not
break objects that had depended on it.
Let's look at this by example. Consider what happens if
you press the accelerator in a car - it speeds up. The
wonder of a car is that you don't have to know anything
whatsoever about the functioning of the engine in order
to accelerate. You just depress the gas pedal and go.
And this is the same for any car you use!
Further, how you use the car is independent of how the
engine changes, you always go faster by doing the same
thing - pressing the accelerator. The engine's implementation,
whether it is a 6 litre or a 4 litre, whether it uses the
newest new fangled electro-E-Virtual-Cyber carburetor or not,
is entirely internal. You interact with nothing except its
interface. In fact you don't need to know or even care about
how the engine works!
To abstract away implementation, COM defines an interface
definition language [IDL]. This IDL is used to specify the
abstract characteristics of methods (such as they take parameters
and can return results) such that the concept of methods is
separated from the implementation of methods.
|
If you are a Java programmer, think of COM as being roughly
similar to the way that Javabeans work. When you write a Javabean
and drop it into a Bean-aware development environment, the
environment only knows what your object is capable of because you
have written your object so as to comply with the Javabean pseudo
API.
|
The interface definition language wraps your object
and does nothing else except describe your object
in terms of the methods and properties that it
exposes to the world at large. It is a contract that
your object makes with the COM runtime about what
it is capable of. The implementation of the functionality
is of no importance to COM - it is your responsibility
as a developer to provide it.
As a result, COM does not understand anything other than an IDL.
Thus, if you write an object and you want to package it as a COM
component, you [or your development environment] must define the
IDL that describes your object in terms of COM.
Once the IDL is validly defined, you can plop your object
into any COM-aware environment and other objects can begin to use
it.
|
COM objects run
within a COM runtime. The runtime is
responsible for all the message passing between COM components and
applications, or between COM components and each other. Because your
object is defined in terms of a valid IDL, the COM run time will
have all it needs to do the message passing.
|
What are COM objects?
Introduction to Perl on Windows - Table of Contents
Multiple Interfaces
|
