Method-Resolution Mechanisms
SOM supports three different method-resolution mechanisms: offset, name lookup, and dispatch. These mechanisms are distinguished by the amount of information required about the object, and by the method and method signature known at the time the client application is compiled. The more information that is known at compile time, the more efficiently the method-resolution mechanism can be used. However, having all information hardwired into the client application at compile time reduces the flexibility of the client, as well as its ability to dynamically determine the object, method, or parameters used in a method invocation. As a result, it is useful to have alternative method-dispatch mechanisms available, which may be less efficient, but more flexible.
Offset method resolution is the default mechanism for method invocation on a SOM object. It is appropriate whenever the following are all known at compile time: the method name, the method signature, and the class that introduced the method. Offset method resolution offers a highly optimized path for invoking a method. In SOM, the method tokens in the ClassData structure are actually method-resolution thunks. Using offset resolution, SOM invokes a method by simply calling the appropriate thunk with the arguments needed for the method.
Name-lookup method resolution is appropriate whenever the method signature is known at compile time, but the name of the introducing class or the method name itself is not. Name-lookup resolution is less efficient than offset resolution. However, this resolution mechanism is more flexible because the particular method and object on which that method is invoked can be determined at run time based on heuristic code in the client application.
Dispatch resolution is the least efficient (but the most flexible) of the SOM method-resolution mechanisms. Using dispatch resolution, a programmer can dynamically construct the method call on an object. Dispatch resolution can be described as a dynamic-invocation interface, whereby a request on an object can be constructed and invoked at run time. The dispatch method-resolution mechanism is appropriate if it is desired to have neither the object class, method name, nor method signature compiled into the client application code. The method name, a memory area to hold any result value produced by the method, and a data structure that contains all the arguments needed for the method, are all supplied as arguments to the dispatch mechanism. The object id is the first member of the argument list.
Comparison to COM
Comparing SOM and COM is a bit like comparing the engine of an automobile with its specifications. A car's engine is not a specification. It is the essential piece of the car that generates the vehicle's motion. Similarly, the engine's specification will not impart motion to the car, but rather must first be used to build an engine before a car can be expected to actually move. In this crude analogy, the engine corresponds to SOM and the specification corresponds to COM.
An immediately observable difference between SOM and COM arises from these disparate uses of the term "object model" as a distinction in the type of code that a developer must write in every application. With SOM, a programmer writes code that uses the object infrastructure SOM provides. With COM, the programmer must also write the code that implements many of the rules and guidelines that comprise the COM infrastructure. COM requires this code to appear in every program, regardless of whether it is written manually or can be partially automated with some development tool. Essentially, COM is a set of rules programmers must interpret and follow in order to build these components.
Although frequently discussed, COM currently lacks the cross-machine, distributed-object capabilities of SOM. At the moment, there is no "distributed COM." Microsoft plans to introduce distributed COM in their Cairo operating system slated for beta testing sometime in late 1995.
OLE 2.0, Microsoft's linking and embedding technology, is built using COM. However, Microsoft does not go to very much effort to distinguish COM from OLE 2.0 (the two are bundled together). The major reason for this is that OLE currently represents the only concrete instantiation of COM.
SOM is a complete implementation of a syntax-free, object-oriented, run-time engine--one that has been carefully engineered to have a robust binary interface completely encapsulating implementation detail. This is underscored by the fact that several C++-compiler vendors currently are using SOM for their run-time library. Object-oriented language compilers that utilize SOM as their run time are referred to as "Direct-to-SOM" compilers. Because SOM has been designed to support a broad set of OO semantics, other languages (both object oriented and procedural) can utilize the SOM run time through intermediary mapping layers referred to as SOM "bindings."
Regardless of which approach is utilized (direct-to-SOM or language bindings), the advantage to a developer is that class libraries can be built that sport robust binary interfaces. Client programs may be constructed that are derived from the classes in the library using normal object-oriented inheritance techniques without compromising the ability of the class-library implementor to make evolutionary changes in the library's internals, and without requiring all client programmers to use the same development language. In short, SOM objects are similar to the normal objects in an object-oriented programming language (OOPL), except that their binary interfaces have been made more robust and replaced with language-neutral mechanisms.
Microsoft's COM, on the other hand, while equally effective at hiding an object's implementation details, does not attempt to be a run-time engine for object-oriented programming. In fact, Microsoft questions the appropriateness of today's object-oriented programming languages for exposing the interfaces of an interoperable software component. The COM specification is a way of hiding the OOPL notion of an object and exposing instead the different abstraction called a "Windows Object."
One area in which Windows Objects differ from typical OOPL objects is that of object identity. Windows Objects are not accessed in the same way as OOPL objects. Whereas an OOPL would allow you to designate a particular object with an "object reference" (or a pointer), a programmer never actually obtains a reference to a Windows Object. Instead, Windows Objects are accessed exclusively through their interface reference (pointers), and one must obtain a separate interface pointer for each of the object's interfaces that a programmer needs to use.
For example, if an object O supports three different interfaces (I1, I2, and I3), you could obtain and use references for O's I1, I2, or I3, but never obtain a reference for O itself. If you had a reference for O's I1 and I2, the only way you could even be sure that both of these referred to the same underlying object would be to query O's I1 for a reference to I2, and then see if it was the same I2 reference you already had. In general, this is always possible because COM requires every interface to support the IUnknown protocol. The IUnknown protocol specifies three functions that should appear in every COM interface, and the first of these functions should permit you to obtain a pointer to any of an object's other interfaces.
Notice that the descriptions of COM frequently use words like "should." This is because COM is largely a set of rules that are not actually enforced anywhere. When creating a Windows Object, it is the programmer's responsibility to implement all these rules and to get them right. This is yet another difference between SOM and COM. SOM's semantics are implemented within the SOM run time, while almost all of COM's semantics must be implemented by the developer in each COM object.
In 1987, Peter Wegner of Brown University introduced some order to the OO community by suggesting a subsequently well-accepted taxonomy for classifying object systems and programming languages based on the features and programming paradigms they support. In Wegner's terminology, systems that have classes and support implementation inheritance can be properly called "object oriented," while those without implementation inheritance can be characterized as "object based." This is the significant difference between SOM and COM: SOM is "object oriented" while COM is merely "object based."
The difference in approaches amounts to the fact that SOM permits class libraries to be developed by using conventional object-oriented programming paradigms, and to offer these same paradigms to their clients. COM rejects the object-oriented notion of implementation inheritance in favor of totally different paradigms for client programming. Microsoft calls these new paradigms "containment" and "aggregation," and offers them as an alternative approach for object reuse.
Aggregation and containment are essentially manual techniques for code reuse entirely implemented by developer-supplied code. COM is not involved in aggregation or containment. It simply provides rules about what users must write.
Containment is used if a programmer wants to change some aspect of the implementation of an object. It requires the programmer to encapsulate the object to be modified with another object whose interface includes the same functions as the encapsulated object. The programmer then supplies the new behavior for functions that are to be changed and provides redispatch stubs to call the corresponding function in the encapsulated object for functions that are not changed.
Aggregation is used when a programmer wishes to add functionality to an object, but does not need to change any of its preexisting behavior. Aggregation is really nothing more than an optimized form of containment in which the programmer is not required to write redispatch stubs for each function in the object's interface. However, the ability to support aggregation must be explicitly built into a COM object by the developer, so not all Windows Objects can be used in this fashion.
With SOM, IBM has chosen to solve the fragile base class problem as opposed to constraining a developers' ability to apply widely accepted object-oriented techniques. Developers of SOM objects can employ familiar paradigms such as single inheritance, multiple inheritance, or abstract (interface-only) inheritance.
— F.R. Campagnoni
Frank, a senior software engineer for IBM's object technology group, can be contacted at [email protected].
Copyright © 1994, Dr. Dobb's Journal
