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.
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,