COM objects support one or more interfaces, each of which has a number of methods. An interface is simply a semantically related group of methods or functions that, when invoked, provide some set of services related to the behavior of the object.    As a matter of fact, the only way you can access the services or data associated with an object is through one of its interfaces.

For example, imagine a hypothetical system that models the functionality of a human resources database. In this system, we probably need some way to model the behavior of say, an employee. If we were to implement the employee class as a COM object, we might have several of these interfaces one of which might be used to hire or terminate the employee. Another interface might be designed to update and maintain various aspects of demographic information.

In our sample scenario, the employee object is probably one of many, interrelated objects. For example, there may be a department object that has as one of its’ data elements, or properties, a collection of employees.

If we were to arrange all of the objects in our hypothetical system into a diagram that depicts their interrelationships, you would see a hierarchy of objects. More specifically you would see our object model.

If you’re familiar with Microsoft products, especially from a software development perspective, you’ve probably heard the phrase "object model". If you’re not, object models simply provide a representation of the hierarchy or organization of objects that make up a given piece of software. These object models are somewhat similar to a class hierarchy in C++. However, instead of depicting inheritance relationships between classes, they’re primarily used to describe a program’s ability to serve up objects while in it’s running or active state and to illustrate   implementations of object techniques such as containment or aggregation.

Many popular products on the market today widely publish their object models: the Microsoft Office Suite, Visio, AutoCad and many others.