View figure.
OpenDoc is a set of DLLs with a largely platform-independent, object-oriented programming interface. This section introduces the classes implemented in the OpenDoc libraries and the design goals behind them.
The interfaces to all of OpenDoc's classes are specified in the Interface Definition Language (IDL), a programming-language-neutral syntax for creating interfaces. IDL is part of the System Object Model (SOM), a specification for object binding at runtime. IDL interfaces are typically compiled separately from implementation code, using a SOM compiler. See "Developing with SOM and IDL" for more information.
Because OpenDoc uses IDL and SOM, part editors and other OpenDoc objects created with different compilers or in different languages can communicate. Also, they can be independently revised and extended and still work together.
For more complete information on the OpenDoc class library, including detailed descriptions of all public OpenDoc classes and methods, see the OpenDoc Programming Reference.
OpenDoc is a set of classes whose objects cooperate in the creation and manipulation of compound documents. It is designed to be as platform-neutral as possible. The object-oriented library structure, in which object fields are private, facilitates the replacement of existing code in a modular manner. Also, by using abstract classes and pure virtual methods, it defines a structure for part editors while specifying as little as possible about their internal functioning.
The OpenDoc class library is not an object-oriented application framework in the full sense of the word. That is, even though the design of OpenDoc allows you to create a part editor, it does so at a lower level, and without forcing as much adherence to interface and implementation as is typical for an application framework.
You can create a part editor just as effectively in either way: directly to the OpenDoc library interfaces or indirectly through the interfaces of a framework. The main difference is that if you use a part-editor framework, you have less code to actually implement yourself, and it is easier to ensure consistency in the final product.
The principal classes in the OpenDoc class hierarchy are shown in Figure 21. All classes are derived from the superclass ODObject, itself a subclass of somObject, the fundamental SOM superclass (not shown). The figure shows these categories of classes:
Figure 21. OpenDoc Class Hierarchy (Principal Classes)
For an illustrated discussion of the relationships of the principal OpenDoc objects in terms of runtime references among them, see "Run-Time Object Relationships".
Classes shown in Figure 22 are support classes, consisting mostly of iterators and simple sets. They are all direct subclasses of ODObject.
Figure 22. OpenDoc Class Hierarchy (Support Classes)
Compared to some application frameworks, there is little inheritance in the hierarchy represented in Figure 21 and in Figure 22; OpenDoc instead makes extensive use of object delegation, in which objects unrelated by inheritance cooperate to perform a task. This relatively flat inheritance structure preserves the language-neutral flavor of OpenDoc and improves ease of maintenance and replaceability.
The OpenDoc classes can be divided into these three groups, based on how a part editor might make use of them:
The following sections summarize these groups of classes.
The OpenDoc classes listed in this section are abstract superclasses that you are intended to subclass if you wish to implement their capabilities.
The class ODPart is central to OpenDoc; it is the one class that you must subclass to create a part editor. ODPart represents the programming interface that your part editor presents to OpenDoc and to other parts.
ODPart is an abstract superclass with many defined methods. When you subclass ODPart, you must override all methods, but you need to provide meaningful implementations only for those methods that represent capabilities actually supported by your part editor. The rest can be stub implementations.
If your part is a container part you must provide an iterator class (a subclass of the abstract superclass ODEmbeddedFramesIterator) to allow callers to access all of the frames directly embedded in your part. Also, Metaclass M-ODPart is required to register your part with OpenDoc.
OpenDoc provides these classes specifically for enhancing its features:
The OpenDoc classes listed in this section implement most of the OpenDoc features that your part editor uses. By using or instantiating objects of these classes, your part can function within an OpenDoc document and can embed other parts.
These classes are never directly instantiated. The classes ODPart and ODEmbeddedFramesIterator, mentioned in the previous section, are abstract superclasses. Other abstract superclasses are mentioned in "Classes for Extending OpenDoc".
The abstract superclasses in the following list are special. They define the basic inheritance architecture of OpenDoc. You should not instantiate these classes and probably would never directly subclass them. In developing a part editor, you would use or subclass one of their existing subclasses.
These classes are implemented in ways unique to each platform that supports OpenDoc. Some represent objects that are created only by OpenDoc, whereas others represent objects that your part editor may need to create.
There is only one ODSession object. Part editors and other OpenDoc objects cache a reference to the single ODSession object for performance reasons. The OpenDoc run time calls ODSession to instantiate all of the OpenDoc library objects (such as ODDispatcher, ODWindowState, and ODArbitrator) and initialize them. ODSession also keeps internal references to these OpenDoc objects, so it is a handy thing to use to access other objects.
These classes exist mainly as services for other classes to use:
View figure.