Interfaces and Implementation

So far, we've talked only in general terms about how we can pass some relevant values to a component and ask it to perform a task for us. We haven't yet talked about how we tell the component what we want it do, or how we pass in the required values. That's what this section is about.

 

One of the key characteristics of all COM components is that they are able to perform tasks for us without telling us how the task is going to be performed. To achieve this, the component must give us clearly defined information saying what the component can do, what type of information it expects us to pass, and what it will return when the task is complete. In other words, we need to know what methods the component exposes, the parameters that each method expects, and the return value from each method. In order to facilitate this, COM distinguishes the description of a component's functionality from its internal workings.

 

q        This description of the component's functionality is defined by the component's interface. A component can have many interfaces, but related methods are generally grouped together within the same interface. A lot of people in the COM world (including the authors of this book!) agree that interface-based programming is the single most important and powerful aspect of COM.

q        The 'internal workings' of the methods and properties—that is, the code that allows them to perform their tasks—is generally referred to as the component's implementation.

 

An interface is really nothing more than a list of methods, properties and events (you'll meet the second and third of these terms in a moment). When we want to use the component, the interface tells us how to do it. The interface doesn't give any details of the component's implementation, but its existence implies a promise that the functionality it describes will always be available.

 

The distinction between interface and implementation is an important one. It's the interface that provides the link between our applications and the component itself. We can replace an old component with a new one that has a different implementation, provided that the new component provides the same interface as the old one. Otherwise, applications designed to use the original interface may break.

Understanding Interfaces

To help us understand interfaces, let's think about cars. We're going to model a car in terms of a component. If you want to be really imaginative, you can pretend that you're an ASP page (rather than a human being) driving the car. The car component provides functionality that can be defined by a number of interfaces. For example, the component has an interface that defines how you drive the car—we'll call it IDrive (by convention, interface names often begin with I).

Methods

The IDrive interface has these methods: