Designing, Building, and Working with COM-Based Components
- Rule 2-1: Think in Terms of Interfaces
- Rule 2-2: Use Custom Interfaces
- Rule 2-3: Define Custom Interfaces Separately, Preferably Using IDL
- Rule 2-4: Avoid the Limitations of Class-Based Events with Custom Callbacks
- Rule 2-5: Be Deliberate About Maintaining Compatibility
- Rule 2-6: Choose the Right COM Activation Technique
- Rule 2-7: Beware of Class_Terminate
- Rule 2-8: Model in Terms of Sessions Instead of Entities
- Rule 2-9: Avoid ActiveX EXEs Except for Simple, Small-Scale Needs
This chapter is from the book
This chapter is from the book
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.
){kind=link}
Figure 2.1 Client accessing an object through an interface
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 a set 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:
Dim rEmp As CEmployee '** reference to default interface Set rEmp = New CEmployee rEmp.ReadFromDB txtName.Text = rEmp.Name txtSalary.Text = Format(rEmp.Salary, "currency")
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.