The System Object Model (SOM) is a language-independent specification for object-oriented programming (OOP). It consists of a set of utilities and interfaces for creating objects. This section provides a brief introduction to the System Object Model; for a more complete explanation, see OS/2 Version 2.0 - Volume 4: Application Development. That document also contains a fuller discussion of OOP concepts.
SOM implements all the essentials of OOP, including inheritance, encapsulation and polymorphism. Objects are organized into classes in a hierarchical manner and subclasses may inherit behaviors and characteristics from their parent (or super) classes.
SOM is language-independent. With suitable bindings any programming language may be used to implement the methods of an object class. For example, a class written in COBOL could then be used or even subclassed by another class written in Smalltalk/V**. However, so far the only language for which such bindings are available is C.
One of the great benefits of building WPS objects using SOM is that SOM implements the concept of inheritance. All objects are grouped into classes, and characteristics and behavior common to more than one class can be defined as methods in a superclass which are then inherited by all child (or sub) classes. Many common methods such as these are defined at the system level, in object classes supplied with OS/2 V2.0, and may be inherited by application-specific object classes.
An application developer may choose to enhance a system-supplied method: for example, providing a more advanced level of drag/drop functionality to a Workplace Shell object class. The developer may create a new object class as a subclass of the system-supplied object class. The subclass need override only those methods that are invoked in drag/drop operations. Other methods may simply be inherited from the super class.
It is important to understand that SOM is a general-purpose implementation of object-oriented programming, and may be used for any OOP programming under OS/2. On the other hand, the class hierarchy it provides is very limited, consisting as it does of only three classes, so a great deal of work would be required to implement classes if SOM were to be used for general-purpose object-oriented programming. In practice the only use to which most programmers will put the SOM is in developing the Workplace Shell objects that will form part of their applications.
OIDL and the SOM Compiler
Non-OOP languages such as C lack the language constructs for defining the classes, methods, instance data and so on that are needed when developing OOP objects. Even OOP languages which are designed for this can only do so for applications that are implemented entirely in one language. For these reasons, SOM provides its own language for defining classes, called Object Interface Definition Language (OIDL). The details of a class, its instance variables, methods and the name of its superclass, are all defined using OIDL, and are placed in a file known as the Class Definition File.
The class definition file is used as input to the SOM compiler, which uses the information to generate several new files, such as C header files, a module definition file to be used when linking the object, and a skeleton C source file containing a prototype function for each method defined in the OIDL. The programmer inserts the application function he requires into this source file to implement the methods he wants, and then compiles and links the program in the usual way to produce DLL containing the object class.
A class definition file contains the following sections:
Include Section