COM+ Programming with Visual Basic

Chapter 3. How Interfaces Work Internally

In the last chapter, you learned the benefit of interfaces at the user level. You learned why we need interfaces conceptually and how to define and use them. In this chapter, you are going to learn what interfaces really are at the memory level. In so doing, you are going to learn some of the core rules of COM. You are going to see the problems that existed before COM and how the COM rules make it possible to overcome those problems.

Warning

This chapter is not for the weak of heart. If you do not want to know how interfaces work internally, feel free to skip this chapter for now and revisit it later.

Life Without Interfaces

Let’s try to imagine life before COM and also life without classes. That would mean that you have user-defined types (UDTs) that represent components and code modules that have global functions. This is not much different than life with VB 3. Also, imagine that the latest version of VB did allow you to create DLLs.

Now suppose that you are designing a banking application. Understanding the benefit of separating code that will be shared among several applications, you define a UDT inside the DLL to represent an account:

Enum AccountTypeConstants
    Checking = 1
    Savings = 2
End Enum

Type Account
    AccountType As AccountTypeConstants
    Active As Boolean
    Balance As Currency
End Type

The UDT has three data members: AccountType, Active, and Balance. The AccountType member in the structure refers to an enumerated type, AccountTypeConstants ...