The design of COM centers around the concept of an interface: Classes expose interfaces, and clients communicate with objects via these interfaces. Although VB can hide most aspects of interface-based programming, it's far better to be informed and to decide for yourself how much VB hides—and how much you explicitly embrace. If you are new to interfaces, rule 2-1 will get you started. Then, examine 8 more rules governing COM techniques.

This chapter is from the book

Microsoft's Component Object Model is an important technology for
sharing class-based code. The beauty of COM is that it is language independent,
allowing developers to work in the language of their choice. It was VB, however,
that first opened the door to widespread COM development.

The design of COM centers around the concept of an interface: Classes
expose interfaces, and clients communicate with objects via these interfaces.
Although VB can hide most aspects of interface-based programming, it's far
better to be informed and to decide for yourself how much VB hidesand how
much you explicitly embrace. If you are new to interfaces, rule 2-1 will get you
started. We then encourage you to embrace fully interface-based design (rules
2-2 and 2-4), and to do so using tools outside VB (rule 2-3). Once defined, an
interface is considered immutable to maintain compatibility as the component
evolves. Compatibility is a subtle issue, and is the subject of rule 2-5.

The remaining rules focus on other important but less traveled techniques
with respect to COM: proper COM activation and termination (rules 2-6 and 2-7),
high-level class design (rule 2-8), and the move away from ActiveX EXE servers
(rule 2-9).

Note that you may come across some COM-related terms that aren't defined
in great detail: in-process DLL, GUIDs, registering a
server, COM activation, and everyone's favorite IUnknown.
Some of the rules assume a basic COM background, so readers new to COM may need
to consult one of the many available COM texts. Or, you can review the free
online tutorial designed for VB programmers at
http://www.develop.com/tutorials/vbcom.

Rule 2-1: Think in Terms of Interfaces

An interface defines a communication protocol between a class and a
client (a user of that class). When a client references an object, the interface
associated with this reference dictates what the client can and cannot do. Conceptually,
we depict this relationship as shown in Figure
2.1. Note that an interface is represented by a small "lollipop"
attached to the object. This symbolizes the fact that an interface is separate
from, but a conduit to, the underlying implementation.

But what exactly is an interface? Consider the following employee class
CEmployee:

'** CEmployee: class
Private sName As String
Private cSalary As Currency
Public Property Get Name() As String
Name = sName
End Sub
Public Property Get Salary() As Currency
Salary = cSalary
End Salary
Public Sub ReadFromDB()
... '** read from a database into private members
End Sub
Public Sub IssuePaycheck()
... '** issue employee's paycheck
End Sub

Clients have access only to the public membersin this case,
Name, Salary, ReadFromDB, and IssuePaycheck.
These members constitute what is called the default interface of
CEmployee. In general, an interface is simply aset of
signatures denoting the public properties and methods. Because a class must
expose at least one public member to be useful, this implies that every class in
VB has at least one interfaceits default.

The key point is that once an interface is published and in use by one or
more clients, you should never change it. Doing so will break compatibility with
your client base. For example, suppose our CEmployee class is compiled
in a stand-alone COM component. Now consider the following client code written
against CEmployee's default interface:

If you were to change the name of CEmployee's public methods or
properties and rebuild the COM component, this client code would no longer
compile. If the client code was already compiled into an EXE, changing the type
of Name or Salary and rebuilding the COM component would cause
a run-time failure when executing the client. In fact, any change to a public
signature represents a change to an interface, and leads, ultimately, to some
kind of error in code using that interface.

As a class designer, what changes can you safely make to your components over
time? Because clients do not have access to private members, these can be
changed at will. Of course, implementation details can also be modified, as long
as the result is semantically equivalent. Lastly, note that although you cannot
delete public members from an interface, you can add properties and
methods without breaking compatibility (see rule 2-5 for a complete discussion
of compatibility).

Thinking in terms of interfaces, and thus separating interface from
implementation, helps you focus on a critical aspect of software development:
maintaining compatibility as a system evolves. The next rule encourages you to
take this one step further and actually design your classes in terms of
explicit, custom interfaces. The result is that your systems become more open to
change.