object n 1 syn THING, article; rel doodad; gadget 2 syn THING, being, entity, individual, material, matter, stuff, substance.
—Webster's Collegiate Thesaurus, Merriam-Webster, 1976
Whenever you hear about objects, you probably have the same nagging question that I often do: just what is an object? For all the highly charged political and religious battles over this question, objects are simply things. The half-empty glass of water on my desk (my doctor says I should be drinking more) is a thing, just as the 12 CDs in the complete collection of Beethoven's piano sonatas are things, just as the button control on my computer screen is a thing.
Out of curiosity, I ventured to look up a suitable definition of thing in Webster's companion dictionary to my thesaurus. (These too are things.) The best of the 10 definitions given is "3 b: the concrete entity as distinguished from its appearances." This definition has one primary implication: my glass of water the object is a glass of water—the object is not its look, its feel, or any other aspect of what I might call its interfaces, sensory or otherwise. Yet because I perceive the world through my senses, these interfaces define how I interact with this object, what I can do with the object, and how I use it. In other words, the true essence of an object is unavailable to me through my senses, so I'm left with no real way to discern the true object. This is, of course, one of those dilemmas that have occupied philosophers for the last, oh, 3000 years or so.
But whether I really know the object's true nature is immaterial to whether I can actually make use of the object. Through the interface of my glass of water, I can certainly make use of it by picking it up, tilting it so that the water runs into my mouth, refilling it when it's empty, and so on.
The separation between what an object is and how that object is used by something external is at the core of how we understand objects in the Component Object Model (COM) (and thus OLE) sense. Again, because OLE is concerned with component integration and components are built of objects, it is our present interest to learn how these objects work, which means learning about COM, the object model. In Chapter 1, you saw what OLE calls an interface and learned how objects support multiple interfaces. This chapter explores these ideas further by looking at how to define and identify an interface, how to use and implement an interface in both C and C++ (proving that you can work with COM and OLE in C, although this will be the only time straight C is used in this book), and various techniques for implementing multiple interfaces, such as C++ multiple inheritance. This chapter will describe the globally unique identifiers (GUIDs) that are used to identify interfaces and object classes and introduce registry considerations that will be cropping up again and again in this book. We will also examine reference counting rules and considerations, standard COM task memory management, standard error types, interface properties, and some glorious details about the ever-so-important QueryInterface function that we met in Chapter 1. We'll see exactly how QueryInterface supports the notion of "robust evolution of functionality over time."
I'll refer mostly to COM instead of OLE in this chapter because COM is the primary technology involved with these topics. In addition, this chapter doesn't exactly follow the convention of placing topics unrelated to programming mechanisms in the first sections of the chapter. Some important information about memory management and special types of objects called enumerators appears at the beginning of some of the programming sections, and earlier sections even introduce some OLE/COM API functions that are of particular interest. The reason for this break from the convention is that the information here, as part of the Component Object Model, is central to everything else in OLE. It is all well worth your time.
Through the course of this chapter, we'll discover COM's answer to the question "What is an object?"—which will serve us well throughout this book. Then we can truly begin to see how a button control or the Beethoven CD I'm listening to (Sonata 17, Op. 31, No. 2, "Tempest") could become an object. What matters is not the nature of the thing, but how we communicate with that thing through whatever interfaces it shows us.