All evolution in thought and conduct must at first appear as heresy and misconduct.
—George Bernard Shaw (1856–1950)
Many years from now, a Charles Darwin of computerdom might look back and wonder how the Microsoft Windows API (Application Programming Interface) evolved into an object-oriented operating system in which most of the "API" is provided through the objects. The technology known as OLE is the genesis of this transformation. It will change how you program—and eventually how you use—Windows. In the beginning, you'll probably regard it as utterly strange and difficult, no matter what your background. But don't feel too threatened. OLE doesn't ask you to throw away any knowledge you've accumulated. OLE preserves most of your knowledge and your code—extending the reach of both to help you reach new heights in software. OLE exists to facilitate and enable the integration of components, either parts of the system of applications or simply stand-alone elements, and it is the capacity for integration that creates a tremendous opportunity for innovation and growth.
Most people involved in the computer industry acknowledge the value of objects or object-oriented programming—whatever these things are. An object offers a certain set of features that define its functionality and the information it manages. Objects are powerful because a single pointer or other reference to an object provides access to all that object's functionality and content. Without objects, programs usually have to maintain multiple variables and pass them to isolated functions to achieve the same ends, adding greatly to complexity. By grouping such variables and functions in a single unit, an object, you create a layer of abstraction that simplifies many programming tasks and provides additional power. This abstraction is a key to extensibility, where new types added into a system can appear and act as existing types.
OLE's contribution to "objects" is threefold. First, OLE enables the integration of components—packages of one or more objects—that object-oriented languages such as C++ cannot, and in that way OLE strongly complements such languages. Second, OLE works independently of programming languages through a binary standard, allowing the oldest legacy code to integrate as a component alongside the newest object-oriented code. Furthermore, objects in OLE share the characteristics of all objects: they are encapsulated, they are polymorphic, and they are reusable. OLE is often denounced as heretical because of minor differences between OLE objects and other objects. OLE's language independence accounts for most of the differences. Such accusations fail to recognize the third category of OLE's tremendously powerful innovations—its concept of object "interfaces" and the idea that objects can have multiple interfaces, each of which represents support for a feature. These interfaces are, literally, different ways of communicating with an object—that is, accessing its functionality and its information. The abstraction of interfaces thus simplifies even more programming tasks, some heretofore impossible.
So while objects are very powerful because they factor functionality and information into tangible units, OLE takes it one step further and factors that functionality and information into related groups, which provides a way for the client or user of an object to ask the object—at run time—which features it supports. This arrangement makes it possible for the independent development and deployment of components over time, without requiring any recompilation of anything else in the system, without requiring a restart of the system, and without having to hassle with compatibility problems. OLE solves such problems, making evolutionary object-oriented component integration possible.
OLE is, at its core, a collection of component services accessed through objects that expose specific interfaces. You can customize some of these services with objects of your own that hook into this core, and if the services you want are not part of OLE, you can also create your own custom services using exactly the same mechanisms. In this sense, OLE is an extensible service architecture, in which a custom, or extended, service transparently becomes part of the core set of services and is immediately available to everything else in the system.
OLE is built on a foundation, the Component Object Model (COM) as it's called, that is both language independent and location independent. Language independence means that you can use any language to implement components as long as the programming tool in whatever language supports the idea of an OLE interface. With OLE, you can encapsulate an existing piece of code as an object without having to necessarily rewrite that code. Location independence means that these components and objects can be implemented and shared in separate dynamic link libraries (DLLs), or executables (EXEs) on the same machine or across machines.1
After defining and exploring exactly what OLE is, we'll take a look at OLE's concepts of components, objects, and interfaces. We'll then briefly examine each specific OLE feature (or technology), describing how your software might take advantage of it (that is, profit from it). By using these features today, you can begin to transform your software to take advantage more readily of the future evolution of Windows (that is, profit from it tomorrow), which is going to involve not only today's OLE but also evolutionary enhancements that Microsoft—and others—will be adding in the future. OLE might seem like heresy today. But the fact is that OLE is a powerful evolution of "objects," and someday Darwin's successor will have plenty to say about OLE—the origin of a new species of incredibly sophisticated and powerful software.
1 At the time of writing cross-machine OLE is not yet available although the OLE architecture is designed to anticipate such capabilities. |