JPH07105005A - オブジェクト指向プログラミングにおけるメタクラス派生の方法および装置 - Google Patents

Abstract

(57)【要約】 【目的】クラスのメタクラスを派生するためのシステ
ム、メソッドおよびプログラムを開示する。 【構成】本発明は、情報の中立的セットを使用する。新
しいクラスを定義する情報は、解析され、コンパイルさ
れ、オブジェクト・ファイルを作成するため目標言語コ
ンパイラへメソッド情報とともに入力される結合ファイ
ルを生成する。連係編集後プログラムの実行時に、オブ
ジェクトの各定義されたクラスは、クラス・オブジェク
トと呼ばれる対応するオブジェクトによって実行され
る。上記のクラス・オブジェクトの親はその定義によっ
て決定され、上記のクラス・オブジェクトのクラスは、
クラス・オブジェクトの親クラスに従って実行時に自動
的に派生され作成されるメタクラスである。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、一般に、オブジェクト
指向の適用業務の改善に関連し、特に、オブジェクト指
向システムにおいてサブクラス化によって新しいクラス
のメタクラスを派生することに関連する。

【０００２】

【従来の技術】ワークステーション・ソフトウェアの開
発者の間で、オブジェクト指向プログラミング（または
ＯＯＰ）は、重要な新しいプログラミング技術として、
ますます認められている。従来のソフトウェア開発パラ
ディグム(paradigms)と比較して改善されたプログラマ
生産性をもたらし、ソフトウェア再利用と拡張性増大の
機会を提供する。しかしながら、オブジェクト指向技術
が効果的に主要な商用ソフトウェア製品に浸透している
とはいえない現状である。特に、オペレーティング・シ
ステムは、この新しい技術を受容することに躊躇してい
る。

【０００３】多くの新しいプログラミング技術と同様
に、ＯＯＰ概念の初期の表現は、各々ある特定の局面を
開拓するために設計された新しい言語およびツール・キ
ットの作成に焦点を当てた。Smalltalkのようないわゆ
る純粋のオブジェクト指向言語は、そのセマンティック
(semantics)が伝統的手続き（プロシージャ）指向シス
テム・アーキテクチャからの明確な乖離を表わしている
ため、（仮想機械としてしばしば知られている）完全な
実行時システム環境を仮定しているが、一方、Ｃ＋＋の
ようなハイブリッド言語は、実時間サポートをさほど必
要とせず、オブジェクト作成プログラムとそれを使用す
るユーザ・プログラムとの間の緊密な結合を生じる場合
が多い。オブジェクト作成プログラムとそれを使用する
ユーザ・プログラムとの間の緊密な結合は、オブジェク
ト作成プログラムにおける変更が単純な場合でも変更が
行われれば必ずユーザ・プログラムの再コンパイルを必
要とする。そのようなシステムの例は、アメリカ合衆国
特許 4,885,717、4,953,080および4,989,132 に見られ
る。

【０００４】

【発明が解決しようとする課題】異なる言語およびオブ
ジェクト指向ツール・キットが、ＯＯＰの異なる局面を
強調するため、その結果開発されるソフトウェアの有効
範囲は、しばしば制限される。例えば、Ｃ＋＋プログラ
マは、Smalltalkで開発されたオブジェクトを簡単には
使用することができなく、逆にSmalltalkプログラマ
は、Ｃ＋＋オブジェクトを効果的に使用できない。ある
言語で実行されたオブジェクトおよびクラスは、他の言
語によって簡単に使われることができない。不幸にし
て、上記の点は、コード再使用の増加というＯＯＰの主
要な利点の１つを著しく損なうことになる。オブジェク
ト指向言語およびツールキットの限界は、実質的に、イ
ンタオペラビリティ（システム間操作性）に対する障害
となる。

【０００５】M.H. Conner その他によるアメリカ合衆国
特許出願番号 805,668「The SystemObject Model Objec
t Interface Definition Language（システム・モデル
・オブジェクトのオブジェクト・インターフェース定義
言語）」に記載されているように、ＳＯＭ（システム・
オブジェクト・モデルすなわちSystem Object Modelの
略称で、本明細書で以下ＳＯＭと呼称する）と呼ばれる
新しい言語中立型オブジェクト指向プログラミング・メ
カニズムは、上述のような従来技術の諸問題を軽減す
る。ＳＯＭにおいて、プログラマは、親クラスからの特
性が継承または上重ねされるサブクラス化と呼ばれるプ
ロセスによってオブジェクトの新しいクラスを定義する
ことができる。オブジェクトのクラスそれ自身は、「ク
ラス・オブジェクト」というオブジェクトである。さら
に、ＳＯＭにおいてはあらゆるオブジェクトはあるクラ
スのインスタンスであるので、各クラス・オブジェクト
は、また、あるクラスのインスタンスでなければならな
い。クラス・オブジェクトのクラスは、「メタクラス(m
etaclass)」と呼ばれる。ＳＯＭの能力を最大限に発揮
するために、プログラマは、ある特定のクラス・オブジ
ェクトに関しメタクラスを指定することができなければ
ならない。しかし、プログラマがメタクラスを指定する
ことが許されるとしても、このメタクラスが親クラスか
らのサブクラス化によって開発されるクラス・インスタ
ンスを完全にサポートしないことは、特に複数の親クラ
スをサブクラス化することによって新しいクラスが派生
される場合、起こり得ることである。

【０００６】従来技術は、この問題に解答を与えなかっ
た。クラス・オブジェクトを作成するSmalltalkのよう
なその他のオブジェクト指向言語では、プログラマは明
示的にメタクラスを指定することを制限され、これによ
って、クラス・オブジェクトを定義するという潜在的利
点が制限される。更に、Smalltalkにおいては、プログ
ラムは、新しいクラスを派生する１つ以上の親クラスを
指定できない。

【０００７】

【課題を解決するための手段】上述の問題に対する解答
を提供するため、言語中立的オブジェクト指向プログラ
ミング・システムを提供することが、本発明の目的であ
る。当システムにおいて、(1)各オブジェクトは、ある
特定クラスのインスタンスであり、(2)クラスは、サブ
クラス化によって派生されるオブジェクトであり、(3)
サブクラス化によって派生されるいかなるクラスのクラ
スも、システムによって自動的に派生される。

【０００８】新しいクラスのため、複数の親クラスをサ
ブクラス化することによって定義されるメタクラスを自
動的に派生することは、本発明のもうひとつの目的であ
る。

【０００９】サブクラス化によって派生される新しいク
ラスのためのメタクラスの指定を可能とすることは、本
発明のもうひとつの目的である。

【００１０】本発明の上記およびその他の目的は、本発
明の好ましい実施例において、プロセッサのメモリにお
ける一組の命令動作によって達成される。サブクラス化
によって派生されるべきオブジェクトの新しいクラスの
ための言語中立的オブジェクト・インターフェース定義
言語（Object Interface Definition Language、以下Ｏ
ＩＤＬと略称する）を含むファイルが、ディスクまたは
他の記憶媒体から取り出され、コンピュータ・メモリ上
のコンパイラへの入力となる。コンパイラは、ＯＩＤＬ
定義ファイルを中間形式へ変換するツールである。中間
形式は、エミッタへの入力となる。エミッタは、中間形
式ファイルを、特定の目標プログラム言語のために表さ
れるオブジェクトの新しいクラスをどのように作成する
かをプロセッサに命令する結合に変換するために使われ
るユーティリティ命令の集合である。結合は、目的モジ
ュールを生成する特定目標言語用のコンパイラへの入力
となる。最後に、目的モジュールは、ロード可能モジュ
ールを作成するために連係編集される。ロード可能モジ
ュールは、そのオブジェクト特有の機能性を必要とする
いかなる適用業務プログラムにも利用されることができ
る。

【００１１】実行される時、サブクラス化によって定義
される新しいクラスのための結合は、その新しいクラス
がインスタンスであるもうひとつのクラスの自動的派生
を起動する。派生されたメタクラスは、新しいクラスを
構築、初期化するため結合によって使用され、新しいク
ラスの親クラスの各々から局面(aspects)を継承し、必
要なら継承された局面に上重ねし、新しいクラスに特有
の新しい局面を加える。新しいクラスを構築し、初期化
するために使われるメタクラスは、プログラマが指定で
きる任意選択のメタクラスと、新しいクラスの親クラス
を構築し初期化するために使われたメタクラスとからの
サブクラス化によって自動的に派生される。

【００１２】

【実施例】本発明は、好ましくは、ＩＢＭ社から発売さ
れているＩＢＭ ＰＳ／２コンピュータに常駐するオペ
レーティング・システムを構成するものとして実施され
る。図１では、本発明に従う代表的ハードウェア環境と
して、伝統的マイクロプロセサのようなＣＰＵ１０やシ
ステム・バス１２を経由して相互接続する数多くの他の
装置を持つワークステーションの典型的ハードウェア構
成が示されている。図１のワークステーションには、Ｒ
ＡＭ１４、ＲＯＭ１６、ディスク装置２０のような周辺
装置をバスに接続するための入出力アダプタ１８、キー
ボード２４やマウス２６、スピーカ２８、マイクロホン
３２、タッチスクリーン装置（図示されてない）のよう
なその他のユーザ・インタフェース等をバスに接続する
ためのユーザ・インタフェース・アダプタ２２、ワーク
ステーションをデータ処理ネットワークに接続するため
の通信アダプタ３４、および、表示装置３８をバスに接
続するためのディスプレイ・アダプター３６とが含まれ
る。ワークステーションは、その上に常駐するＯＳ／２
型オペレーティング・システムとツールキットとして本
発明を構成するコンピュータ・ソフトウェアを備え持
つ。

【００１３】オブジェクト指向プログラミングは、高品
質の、再使用可能なコードを開発する上で重要な方法と
してその基盤を急速に確立している。本発明は、クラス
・ライブラリおよびオブジェクト指向プログラムを開発
するための新しいシステムを含む。このシステムは、シ
ステム・オブジェクト・モデル（ＳＯＭ）と呼ばれる。
発明を理解する際の助けになるように、オブジェクト指
向プログラミング、ＳＯＭ、および他のオブジェクト指
向言語との比較について以下詳細な記述を行う。はじめ
に、オブジェクト指向プログラミングを紹介する。

【００１４】ソフトウェア産業分野で比較的最近開発さ
れたものが、オブジェクト指向プログラミングである。
オブジェクト指向プログラミング言語（以下ＯＯＰＬと
略称）は、当産業で広く使われている。オブジェクト指
向データベース（ＯＯＤＢ）は幅広い関心を集めはじ
め、さらにオブジェクト指向設計・分析ツール（ＯＯＤ
Ａ）は、人々がシステムを設計しモデル化する方法を変
更しつつある。

【００１５】オブジェクト指向プログラミングは、その
親密な"いとこ"である構造化プログラミングと対比する
ことによって最もよく理解される。両方とも、複合的ソ
フトウェア・システムの複雑さを管理するという同じ基
本問題を取り扱うことを試みる。構造化プログラミング
は、機能モジュールの階層化されたセットとしてシステ
ムをモデル化する。これらのモジュールは、ピラミッド
のような形態で築き上げられ、各層は、システムのより
高いレベルの概要を描写する。構造化プログラミング
は、システムの動作をモデル化するが、システムの情報
をモデル化することに対するガイダンスは殆ど与えな
い。一方、オブジェクト指向プログラミングは、一組の
協調的オブジェクトとして、システムをモデル化する。
構造化プログラミングと同様に、システムの動作上の複
雑さを管理することを試みる。しかし、システム情報の
複雑さを管理することを試みる点において、オブジェク
ト指向プログラミングは、構造化プログラミングを凌駕
する。

【００１６】オブジェクト指向プログラミングが、シス
テムの動作上と情報上の両者の複雑性をモデル化するの
で、システムは、単によく「構造化された」場合より
も、非常によく組織化されるという傾向がある。オブジ
ェクト指向システムはよりよく組織化されるので、より
簡単に理解し、デバッグし、維持し、改良できる。よく
組織化されたシステムは、また、コード再利用に役立
つ。

【００１７】オブジェクト指向プログラミングは、密接
に関係がある情報上および動作上両者の複雑さを管理す
るという二重の問題を想定する。その組織の基本単位
は、オブジェクトである。オブジェクトは、オブジェク
トの状態と呼ばれる関連データとオブジェクのメソッド
と呼ばれる一組の動作を持つ。メソッドは、サブルーチ
ンによって実行される。クラスはオブジェクトの一般的
記述であり、オブジェクト状態を表すデータとオブジェ
クトをサポートするためのメソッドとを定義する。

【００１８】次に、「Ｃにおけるオブジェクト指向プロ
グラミング」を考察する。一般的スタックに関連した情
報を含むデータ構造定義を考察してみる。データ構造
は、スタック構造の上で動作するよう設計された一連の
機能を包含する。基本スタック定義を前提として、この
データ構造の複数のインスタンスが、プログラム内で宣
言される。

【００１９】Ｃにおける一般的スタック定義は、以下の
ようになる。

【００２０】 一般的スタック関数の定義は、以下のようになる。

【００２１】 Stack *creates(); /* 新しいスタックにメモリを割り当て、初期化する */ void *pop( /* スタックからエレメントを取り出す */ Stack *thisStack); void push( /* スタックに挿入 */ Stack *thisStack; void *nextElement); このような関数がどのように書かれるか、ほとんどのＣ
プログラマは、想像することができるであろう。例え
ば、<push()> 関数は、以下のようになる。

【００２２】 例えば、解釈を必要とするワードのスタックを作成する
ため、ユーザ・プログラムが次のようにこのスタックを
使用することができる。

【００２３】 この例は、オブジェクト指向プログラミングを検討する
ために使うことができる。クラスは、オブジェクトの定
義である。定義は、オブジェクトのデータ要素とそれが
サポートするメソッドとを含む。<stack>は、１つのク
ラスの１例である。スタックは、2つのデータ要素<stac
kArray>と<stackTop>を含み、３つのメソッド<create()
>と<push()>と<pop()>とをサポートする。メソッドは、
関数のようなものであるが、特定クラスのオブジェクト
上で動作するように設計される。オブジェクトは、クラ
スの特定のインスタンスである。オブジェクト<wordSta
ck>はクラス<Stack>のオブジェクトであるか、または、
<wordStack>はスタックのインスタンスである。

【００２４】あらゆるメソッドは、そのために動作すべ
き特定のオブジェクトを必要とする。このオブジェクト
は、目標オブジェクト、時には、受領オブジェクトと呼
ばれる。<create()>を除く各メソッドは、目標オブジェ
クトへのポインタをその第１パラメータとして持つ点に
注意すべきである。プログラムは、ある与えられたクラ
スの多くのオブジェクトを持ち、そのオブジェクトのい
ずれもクラス・メソッドの潜在的目標でもある。

【００２５】この種の組織には、３つの重要な長所があ
る。第１に、同様の概念が該当する他の状況において再
利用されることができる一般的概念が開発される。第２
に、プログラムに組み込まれる前に充分にテストされる
ことができる自己完結型コードが開発される。第３に、
内部の詳細が隠蔽され、ユーザ・プログラムが関心を持
つ必要のないカプセル化されたコードが開発される。ユ
ーザ・プログラム<main()>は、<Stack>クラスについ
て、その名、それがサポートするメソッドおよびそれら
メソッドへのインターフェース以外は何も知る必要はな
い。

【００２６】次に、「ＳＯＭとＣ＋＋との比較」を考察
する。

【００２７】ＳＯＭは、Ｃ＋＋と多くの類似点を持つ。
両者ともに、クラス定義、継承およびＣ＋＋で仮想メソ
ッドと呼ばれる上書きメソッドをサポートする。両者と
もカプセル化の概念をサポートする。しかし、Ｃ＋＋が
独立型プログラミングをサポートするように設計される
のに対して、ＳＯＭは市販のクラス・ライブラリのサポ
ートに焦点を置く。ＳＯＭとＣ＋＋の大部分の相違は、
この点による。Ｃ＋＋クラス・ライブラリは、バージョ
ンに依存している。一方、ＳＯＭクラス・ライブラリ
は、バージョンに依存しない。新しいＣ＋＋クラス・ラ
イブラリがリリースされると、変更が一般に知られてい
るインターフェースに無関係であったとしても、ユーザ
・プログラム・コードは完全に再コンパイルしなければ
ならない。

【００２８】Ｃ＋＋は、１つの言語Ｃ＋＋でのプログラ
ミングのみをサポートする。ＳＯＭは、多くの言語をサ
ポートするよう設計される。ＳＯＭは、言語というより
むしろ、クラス・ライブラリを定義し、処理し、そして
リリースするシステムである。ＳＯＭは、クラスおよび
メソッドを定義するために使われるが、新しい言語構文
を学ぶ必要なしにメソッドを実行するための言語の選択
は、実行者に委ねられる。

【００２９】Ｃ＋＋は、実行隠蔽またはカプセル化の最
低限度のサポートを提供する。ユーザ・プログラムにリ
リースされなければならないＣ＋＋クラス定義は、プラ
イベートなデータおよびメソッドのための宣言を含むの
が典型的である。ＳＯＭにおいては、ユーザ・プログラ
ムはこれらの実現の詳細に重点を置く必要は絶対なく、
ユーザ・プログラムは、パブリックの情報を含む<.sc>
ファイルを見るだけでよい。Ｃ＋＋は、また、限定的メ
ソッド導出機能を提供するが、ＳＯＭは、オフセット・
メソッド導出、名前照合導出およびディスパッチ導出の
ようないくつかの代替的方法を提供する。

【００３０】ＳＯＭとＣ＋＋との間のもう１つの興味あ
る相違は、クラスについての概念にある。Ｃ＋＋におい
ては、クラス宣言は、構造宣言に非常に似ている。それ
は、実行時に有意性のある特性を持たないコンパイル時
パッケージである。ＳＯＭにおいては、オブジェクトの
クラスは、オブジェクトである。クラス・オブジェクト
は、それ自身（メタクラスと呼ばれる）もう１つのクラ
スのインスタンスである。クラスが常にそのインスタン
スの実現を定義するので、メタクラスは、クラスでもあ
るそのインスタンスが応答するメソッドを定義すること
に対して責任がある。これらのメソッドには、クラスが
そのインスタンスのためのメソッド実現をその親から継
承するメソッドと、クラスが継承されたインスタンス・
メソッド実現を上重ねするメソッドと、クラスが新しい
インスタンス・メソッド実現を加えるメソッドとが含ま
れる。更に、メタクラスは、クラス・オブジェクトにと
って適切なその他の有益なメソッドを定義する。それら
には、例えば、クラスがその名を戻すこと、その親のリ
ストを戻すこと、あるいはそのインスタンスに関し与え
られたメソッドを実現するために使われるプロシージャ
を戻すこと等を可能にするメソッドが含まれる。ＳＯＭ
は、Ｃ＋＋またはSmalltalkのような言語によって例証
されるオブジェクト指向プログラミングの従来技術より
非常に強力である。なぜならば、新しいＳＯＭメタクラ
スを定義することによって、継承を実現するメソッドを
プログラマは実際に再定義することができるからであ
る。従って、新しいサブクラスを定義している時、要求
されるメタクラスを明示的に示すことによって、プログ
ラマは、新しいクラスのオブジェクトに関し特別なサブ
クラス化セマンティックス（意味論）を選択することが
できる。対照的に、Ｃ＋＋、Smalltalkおよびその他の
従来技術が継承をサポートする方法は、プログラマが制
御することができない固定的な局面である。

【００３１】次に、「ＳＯＭの紹介」を行う。

【００３２】ＯＳ／２ ２.０は、ＳＯＭ（システム・オ
ブジェクト・モデル）と呼ばれる言語中立的オブジェク
ト指向プログラミング・メカニズムを含む。上述のスタ
ックに関するプログラムの例のようにオブジェクト指向
プログラムを伝統的言語で書くことは可能ではあるが、
ＳＯＭは、新しいパラディグムをサポートし、手続き型
（または非オブジェクト指向）言語とオブジェクト指向
言語との両方によって使われるように特に設計されてい
る。

【００３３】オブジェクト指向プログラミングの重要な
必要条件は、コード再使用性である。典型的には、コー
ド再使用性は、クラス・ライブラリの使用を通して達成
される。今日のライブラリ技術は、クラス・ライブラリ
が常に特定言語用である点で、制限されている。Ｃ＋＋
ライブラリはSmalltalkプログラマによって使われるこ
とができないし、また、SmalltalkプログラマはＣ＋＋
ライブラリを利用することができない。明きらかに、手
続き型であろうとオブジェクト指向であろうと、どのよ
うなプログラム言語からも使われることができるクラス
・ライブラリを作成するため用いることのできる言語中
立的オブジェクト・モデルを作成することは必要であ
る。

【００３４】ＳＯＭは、殆どの手続き型言語に欠けてい
る３つの重要な機能を導入する。それらは、カプセル
化、継承および同質異像polymorphism（本明細書では
「上書き導出」と呼んでいる）である。

【００３５】カプセル化は、ユーザ・プログラムから実
現詳細を隠蔽することをいう。これは、ユーザ・プログ
ラムが、システムに影響を及ぼす可能性があるような実
現の変更を行うことを防ぐ。例えば、スタックの例にお
いて、Ｃコードに与えられた保護はなかった。ユーザ・
プログラムがスタックの内部データ構造を知っている必
要はないにも拘わらず、ユーザ・プログラムがそのよう
な実現の詳細を見ることを防止する方法はなかった。ユ
ーザ・プログラムが、内部スタック・データ要素を使用
し、場合によってはそれを壊す恐れのあるコードを書く
可能性がある。

【００３６】継承は、派生クラスまたはサブクラスと呼
ばれるオブジェクトのクラスの形態および動作を、親ク
ラスまたはスーパークラスと呼ばれるもう１つのクラス
からの相違増分として、指定するテクニックをいう。継
承の伝統的形態においては、サブクラス化は、親クラス
の形状および動作を継承し、必要とされない継承された
動作を上書きし（無効とし）、新しい動作を加えること
ことによって派生クラスを特殊化するために使用され
る。継承された動作が上書きされるかもしれないが、上
書きされる動作をサポートするために使われるオブジェ
クト状態、またはインスタンス変数は、常に継承され
る。

【００３７】継承あるいはクラス派生は、既存のクラス
から新しいクラスを開発するための特別なテクニックで
ある。この機能は、既存のクラスのより特殊なバージョ
ンである新しいクラスの作成を可能とする。例えば、<D
ebuggableStack>は、<Stack>クラスであるかのように逆
向きにすることはできるが、それでもなお、（例えば、
最上部の値を見るための<peek()>やスタックの完全なリ
スティングを印刷するための<dump()>などの）デバッギ
ング・メソッドをサポートする。

【００３８】継承は、また、コード統合を提供する。例
えば、<GraduateStudent>および<UnderGraduateStudent
>を定義しているクラスは、３番目のクラス（<Studen
t()>）に統合されることができる。従って、<GraduateS
tudent>と<UnderGraduate>は、両者とも共通の親<Stude
nt>から派生され、より特殊化されたクラスとして定義
される。

【００３９】継承は、追加のセマンティックス（意味
論）を導入する。特殊化されたクラスは、より一般化さ
れたクラスから派生されると言われる。一般のクラス
は、親クラス、あるいは時には、基底クラスと呼ばれ
る。特殊化されたクラスは、子クラス、または、時に
は、派生されたクラスと呼ばれる。

【００４０】オブジェクト指向プログラミング・システ
ムの基本セマンティックは、以下の点を保証しなければ
ならない；ある特定のオブジェクト・クラスに適合する
コードは、より特殊化されたオブジェクト・クラスに
も、すなわち、該特定クラスからサブクラス化によって
派生されたオブジェクト・クラスにも適合できなければ
ならない。この保証は、オブジェクト指向プログラミン
グの基本である。かくして、<GraduateStudent>および<
UnderGraduateStudent>はともに<Student>から派生され
るので、それらは両方とも、その共通の親において宣言
されたメソッドを自動的に獲得する。

【００４１】さらに、ＳＯＭにおいて、クラス・オブジ
ェクトは、それ自身オブジェクトであり、このクラス・
オブジェクトが常にコード化できるので、これは、<Gra
duateStudent>および<UnderGraduateStudent>のメタク
ラスが、<Student>のメタクラスに使用できるいずれか
のメソッドを獲得しなければならないケースでもある。
そのようなケースでないとすれば、例えば、<Student>
オブジェクトには適合するが<GraduateStudent>オブジ
ェクトには適合しないようなコードを作成する可能性が
あろう。そして、これは、上記のオブジェクト指向プロ
グラミングの基本原理に反する。これが、プログラマが
新しいサブクラスを定義する場合、ＳＯＭが、常にメタ
クラスを自動的に派生し、新しいクラス・オブジェクト
が、その親（複数）のいずれかがサポートするすべての
メソッドをサポートすることを保証する理由である。

【００４２】他のオブジェクト指向プログラミング・シ
ステムにおいては、（Ｃ＋＋のように）メタクラスがな
いか、あるいは（Smalltalkのように）プログラマがメ
タクラスを定義し、使用することを明示的に禁止してい
る。これら特別の場合、新しいメタクラスを派生する必
要はない。なぜならば、メタクラスが存在しないか、あ
るいは、クラス・オブジェクトがサポートするメソッド
がシステムによって固定されているからである。しか
し、プログラマが、新しいクラスを宣言する時、彼ら自
身のメタクラスを定義し、使用することが可能であれ
ば、プログラマが既存のクラスの任意の新しいサブクラ
スを定義することが可能となるように、これらの新しい
サブクラスのメタクラスが上記のオブジェクト指向プロ
グラムの基本原理を満たすために派生されることは、オ
ブジェクト指向プログラミングの実際的使用にとって不
可欠である。上書きは、メソッド名のみならずクラス階
層の範囲内のクラス位置にも基づいて導出され、起動さ
れるメソッドをいう。これは、クラスを派生する場合、
メソッドを再定義することを可能にする。<printStuden
tInfo()>メソッドは、<Student>のために定義されるこ
とができ、次に、<UnderGraduateStudent>および<Gradu
ateStudent>両者のメソッドを上書きするか、あるいは
再定義する。上書き導出は、目標オブジェクトのクラス
に基づいて導出を行う。目標オブジェクト・クラスが<S
tudent>であれば、<printStudentInfo()>の<Student>バ
ージョンが起動される。目標オブジェクト・クラスが<G
raduateStudent>であれば、<printStudentInfo()>の<Gr
aduateStudent>バージョンが起動される。

【００４３】次に、「ＳＯＭにおけるクラス定義」の考
察を行う。

【００４４】ＳＯＭでクラス・ライブラリを作成するプ
ロセスは、３段階プロセスである。クラス設計プログラ
ムは、クラス・インターフェースを定義し、クラス・メ
ソッドを実行し、最後に結果として生成されるオブジェ
クト・コードをクラス・ライブラリにロードする。ユー
ザ・プログラムは、直接これらのクラスを使用するか、
特定の目的に合わせて変更するか、または完全に新しい
クラスを追加する。

【００４５】ＳＯＭにおいては、クラスは、クラス定義
ファイルを作成することによって定義される。クラス定
義ファイルは、拡張子"csc"を持つファイル名がつけら
れる。最も基本的形式では、クラス定義ファイルは、以
下のような部分に区分される。

【００４６】１. Include部：この部分は、Ｃの<#inclu
de>と殆ど同じように、includeされる（含まれる）べき
ファイルを宣言する。

【００４７】２. Class名およびオプション部：この部
分は、クラス名を定義し、種々のオプションを宣言す
る。

【００４８】３. メタクラス部：このオプションの情報
によって、定義されるクラスのメタクラスを派生する時
に考慮されるべき明示的メタクラスをプログラマが指定
することができる。明示的に指定されたメタクラスがす
べての必要なクラス・メソッドを提供することが派生プ
ロセスの間に決定されるならば、指定されたメタクラス
は、メタクラス派生プロセスの結果であり、従って、新
しいクラスを実現するために使われるメタクラスであり
得る。しかし、一般的には、そのようなケースにはなら
ない。一般的には、派生されるメタクラスは、指定され
たメタクラスとその他のクラスからのサブクラス化によ
って派生される新しいクラスである。

【００４９】４. 親情報部：この部分は、このクラスに
関する親クラスまたは基底クラスを定義する。定義され
るすべてのクラスは、少くとも１つの親を持たなければ
ならない。クラスが既存のクラスから派生されない場
合、その親は、ＳＯＭ定義のクラス<SOMObject>であ
る。そのクラス情報は、ファイル<somobj.sc>に含めら
れる。

【００５０】５. データ部：この部分は、このクラスの
オブジェクトによって含まれるデータ要素を宣言する。
省略時解釈では、データはクラスのメソッドによっての
みアクセスされることができる。

【００５１】６. メソッド部：この部分は、このクラス
のオブジェクトが応答することができるメソッドを宣言
する。省略時解釈では、この部分で宣言されたすべての
メソッドは、クラスのユーザ・プログラムが使用でき
る。

【００５２】クラス定義ファイル<student.csc>は、非
派生 <Student>クラスを記述する。クラス定義ファイル
<student.csc>は以下の通りである。

【００５３】 次に「メソッドを書く方法」を記述する。

【００５４】クラス・メソッドは、クラス・メソッド実
現ファイルで実現される。クラス定義ファイルのメソッ
ド部で定義されるメソッドの各々は実現されなければな
らない。ＳＯＭサポートを行ういかなる言語において
も、それらを実現できる。Ｃが、本発明の仕様に全体に
わたって典型的言語として使われるが、いかなるプログ
ラム言語でも代用できることは、通常の技術を有する当
業者によって理解されるであろう。以下に、student
（学生）クラス・メソッド実現ファイル<student.c>を
例示する。

【００５５】 クラス・メソッド実現ファイル：<student.c> #define Student_Class_Source #include "student.ih" static void setUpStudent(Student *somSelf, char *id, char *name) { StudentData *somThis = StudentGetData(somSelf); strcpy(_id, id); strcpy(_name, name); } static void printStudentInfo(Student *somSelf) { StudentData *somThis = StudentGetData(somSelf); printf(" Id : %s \n", _id); printf(" Name : %s \n", _name); printf(" Type : %s \n", _getStudentType(somSelf)); } static char *getStudentType(Student *somSelf) { StudentData *somThis = StudentGetData(somSelf); static char *type = "student"; return (type); } static char *getStudentId(Student *somSelf) { StudentData *somThis = StudentGetData(somSelf); return (_id); } メソッド・コードが標準Ｃに似ている点注意されるべき
である。最初に、各メソッドは、その第１のパラメータ
として、目標オブジェクトへのポインタ<somSelf>を取
り出す。このパラメータは、クラス定義ファイルにおい
ては暗示的であるが、メソッド実現においては明示的に
される。第２に、各メソッドは、<somThis>と名付けら
れた内部変数をセットする行から開始する。この内部変
数は、ＳＯＭヘッダ・ファイルで定義されるマクロによ
って使われる。第３に、目標オブジェクトのデータ要素
にはその先頭に下線文字"_"が付けられる。下線を付け
られた名は、クラス・ヘッダ・ファイルにおいて定義さ
れるＣ言語マクロを表わす。第４に、メソッドは、メソ
ッド名の前に下線"_"を置くことによって、起動され
る。この下線を付けられた名は、メッセージ導出のため
のマクロを表わし、プログラマはこのプロセスの詳細を
理解する必要はない。

【００５６】各メソッドの第１のパラメータは常に、目
標オブジェクトへのポインタである。これは、以下の目
標オブジェクトのメソッド<getStudentType()>を起動す
るメソッド<printstudentlnfo()>において例証される。

【００５７】 ＳＯＭコンパイラ生成の<student.c> #define Student_Class_Source #include "student.ih" static void setUpStudent( Student *somself, char *id, char *name) { StudentData *somThis = StudentGetData(somSelf); } static void printStudentInfo(Student *somSelf) { StudentData *somThis = StudentGetData(somSelf); /* その他のメソッドに関し同様 */ 次に、「ＳＯＭ使用のメカニズム」を考察する。

【００５８】以下に検討される各クラスに必要とされる
１組のファイルがある。それらのファイルはそれぞれが
異なる拡張子を持つが、上述の例におけるクラス定義フ
ァイル<Student>のように、すべて同じファイル名を持
つ。以下はこれらのファイルの例である。

【００５９】学生(student)クラス・ファイル <student.csc>− これは、クラス定義ファイルである。

【００６０】<student.sc>− これは、クラス定義ファ
イルのサブセットであり、パブリック要素上のコメント
を含め、<.csc>ファイルからのすべてのパブリックの情
報を含む。studentの例に関して、<student.sc>はデー
タ部を除いて<student.csc>からのすべてを含む。この
ファイルは、ＳＯＭコンパイラによって作成される。

【００６１】<student.h>− これは、パブリック・メソ
ッドを起動しそのクラスのパブリック・データ要素をア
クセスするために必要なマクロを含むＣヘッダ・ファイ
ルである。このファイルは、クラスのどのユーザ・プロ
グラムにもincludeされ（含められ）、ＳＯＭコンパイ
ラによって作成される。

【００６２】<student.ih>− <student.h>と同様である
が、これは、メソッドを実現するのに必要とされる付加
情報を含む。これは、<.h>ファイルの実現プログラム・
バージョンであり、クラス・メソッド実現ファイルに含
められなければならない。このファイルは、ＳＯＭコン
パイラによって作成されるが、編集してはならない。

【００６３】<student.c>−メソッド実現を含む。初期
的にＳＯＭコンパイラによって作成され、次に、クラス
実現プログラムによって更新される。

【００６４】次に、「他のクラスからのＳＯＭクラスの
作成」について記述する。

【００６５】他のクラスからＳＯＭクラスを作成する方
法は２つある。それらは、派生（または継承）と構築と
である。

【００６６】最初に派生について述べる。本明細書の例
では、<GraduateStudent>は、その基底クラスまたは親
クラスである<Student>から派生される。

【００６７】派生されたクラスは、基底クラスの特性の
すべてを自動的に拾い上げる。派生されたクラスは、新
しいメソッドの定義と実現を通して新しい機能性を加え
ることができる。派生されたクラスは、また、その基底
クラスのメソッドを再定義することができる。これは、
上書きと呼ばれるプロセスである。たとえば、<Graduat
eStudent>は<setUpGranduateStudent()>をそれが<Stude
nt>から継承するそれらのメソッドに加える。それは、
２つの他の継承されたメソッド、<printStudentInfo()>
および<getStudentType()>を上書きする。それは、<Stu
dent>基底クラスから<setUpStudent()>および<getStude
ntId()>を変更なしに継承する。

【００６８】<GraduateStudent>に対するクラス定義フ
ァイル<graduate.csc>は、以下の通りである。

【００６９】 クラス定義ファイル:<graduate.csc> include <student.sc> class: GraduateStudent; parent: Student; data: char thesis[128]; /* 課題タイトル */ char degree[16]; /* 卒業生学位 */ method: override printStudentInfo; override getStudentType; void setUpGraduateStudent( char *id, char *name, char *thesis, char *degree); メソッド実現ファイル<graduate.c>は以下の通りであ
る。

【００７０】 クラス・メソッド実現ファイル :<graduate.c> #define GraduateStudent_Class_Source #include "graduate.ih" static void printStudentInfo(GraduateStudent *somSelf) { GraduateStudentData *somThis = GraduateStudentGetData(somSelf); parent_printStudentInfo(somSelf); printf(" Thesis : %s \n", _thesis); printf(" Degree : %s \n", _degree); } static char *getStudentType(GraduateStudent *somSelf) { static char *type = "Graduate"; return (type); } static void setUpGraduateStudent( GraduateStudent *somSelf, char *id, char *name, char *thesis, char *degree) { GraduateStudentData *somThis = GraduateStudentGetData(somSelf); _setUpStudent(somSelf,id,name); strcpy(_thesis, thesis); strcpy(_degree, degree); } しばしば、上書きされるメソッドは、その親のオリジナ
ルのメソッドを起動する必要がある。例えば、<Graduat
eStudent> に関する<printStudentInfo()>は、<Graduat
eStudent>特定情報を印刷する前に、<printStudentInfo
()>の<Student>バージョンを先ず起動する。これに対す
る構文は、<printStudentInfo()>メソッドに見られるよ
うに、<parent_MethodName>である。

【００７１】ある与えられた基底クラスは、１つ以上の
派生のために使われることができる。クラス（<UnderGr
aduateStudent>）もまた、<Student>から派生される。
クラス定義ファイル（<undgrad.csc>）は、以下の通り
である。

【００７２】 メソッド実現ファイル<undgrad.c>は以下の通りであ
る。

【００７３】 クラス・メソッド実現ファイル :<undgrad.c> #define UnderGraduateStudent_Class_Source #include "undgrad.ih" static void printStudentInfo( static void printStudentInfo( { UnderGraduateStudentData *somThis = UnderGraduateStudentGetData(somSelf); parent_printStudentInfo(somSelf); printf(" Grad Date : %s \n", _date); } static char *getStudentType(UnderGraduateStudent *somSelf) { static char *type = "UnderGraduate"; return (type); static void setUpUnderGraduateStudent( UnderGraduateStudent *somSelf,char *id, char *name, char *date) { UnderGraduateStudentData *somThis = UnderGraduateStudentGetData(somSelf); _setUpStudent(somSelf,id,name); strcpy(_date, date); } クラスを作成する第２のテクニックは、構築である。構
築とは、別のクラスを使用するクラスをいうが、継承に
はよらない。構築のよい例は、複数の<Student>へのポ
インタの配列を含むクラス<Course>である。各ポインタ
は、course（科目）を受講する特定のstudent（学生）
のアドレスを含む。<Course>は、<Student>から構築さ
れる。<Course>（）に対するクラス定義ファイル<cours
e.csc>は以下の通りである。

【００７４】 クラス定義ファイル:<course.csc> include <somobj.sc> class: Course; parent: SOMObject; data: char code[8]; /* コース・コード番号 */ char title[32]; /* コース・タイトル */ char instructor[32]; /* インストラクター */ int credit; /* 単位数 */ int capacity; /* 席の最大数 */ Student *studentList[20]; /* 受講申し込み学生リスト */ int enrollment; /* 受講申し込み学生数 */ method: override somInit; void setUpCourse(char *code, char *title, char *instructor, int credit, int capacity); − 新しいコースを設定。 int addStudent(Student *student); ― コースへの学生受講を申し込む。 void dropStudent(char *studentId); − 学生をコースから落とす。 void printCourseInfo(); − コース情報をプリント。

【００７５】しばしば、クラスはそのインスタンス・デ
ータを初期状態にするために特別のステップをとること
を要する。<Course>のインスタンスは、有効な状態でア
レイ・インデックスが開始することを確実にするため
に、<enrollment>データ要素を少くとも初期状態にしな
ければならない。新しいオブジェクトが作成される時、
メソッド<somInit()>は、常に呼び出される。このメソ
ッドは、<ＳＯＭObject>から継承され、オブジェクト初
期状態設定が要求される時、上書きされることができ
る。

【００７６】この例は、継承の興味深い特徴である、派
生されたクラスと基底クラスの間の「is-a」関係を示唆
する。派生されるどのクラスも、基底クラスの１つと考
えられる。派生されたクラスは、基底クラスの１つ("is
-a")である。前の例において、いずれの<GraduateStude
nt>も、<Student>の１つ"is-a"であり、<Student>が想
定されるいかなる場所においても使われることができ
る。逆は、真でない。基底クラスは、派生されたクラス
でない。<Student>は、<GraduateStudent>として無条件
に扱われることができない。かくして、配列<studentLi
st>の要素は、複数の<Student>のどれか、または複数の
<GraduateStudent>のどれか、または複数の<UnderGradu
ateStudent>のどれかをポイントすることができる。

【００７７】<Course>に対するメソッド実現ファイル<c
ourse.c>は、以下の通りである。

【００７８】 クラス・メソッド実現ファイル<course.c> #define Course_Class_Source #include <student.h> #include "course.ih" static void somInit(Course *somself) { CourseData *somThis = CourseGetData(somSelf); parent_somInit(somSelf); _code[0] = _title[0] = _instrtuctor[0] = 0; _credit = _capacity = _enrollment = 0; } static void setUpCourse(Course *somSelf, char *code, char *title, char *instrtuctor, int credit, int capacity) { CourseData *somThis = CourseGetData(somSelf); strcpy(_code, code); strcpy(_title, title); strcpy(_instructor, instructor); _credit = credit; _capacity = capacity; } static int addStudent(Course *somSelf, Student *student) { CourseData *somThis = CourseGetData(somSelf); if(_enrollment >= _capacity) return(-l); _studentList[_enrollment++] = student; return(0); } static void dropStudent(Course *somSelf, char *studentId) { int i; CourseData *somthis = CourseGetData(somSelf); for(i=O; i<_enrollment; i++) if(!strcmp(studentId, _getStudentId(_studentList[i]))) { _enrollment--; for(i; i<_enrollment; i++) _studentList[i] = _studentList[i+1]; return; } } static void printCourseInfo(Course *somSelf) { int i; CourseData *somThis = CourseGetData(somSelf); printf(" %s %s \n", _code, _title); printf(" Instructor Name : %s \n", _instructor); printf(" Credit = %d, Capacity = %d, Enrollment = %d \n\n", _credit, _capacity, _enrollment); printf(" STUDENT LIST: \n\n"); for(i=O; i<_enrollment; i++) { _printStudentInfo(_studentList[i]); printf("\n"); } } 特に、メソッド<printCourseInfo()>に留意されたい。
このメソッドは、各student（学生）に関するメソッド<
printStudentInfo()>を起動する配列<studentList>を調
べる。このメソッドは、<Student>に関し定義され、<Gr
aduateStudent>と<UnderGraduateStudent>によって上書
きされる。配列要素がこれらの３つのクラスのいずれを
もポイントすることができるので、コンパイル時に目標
オブジェクトの実際のタイプが何であるかを決定するこ
とは不可能であり、単に目標オブジェクトは、<Student
>、または、<Student>から派生されたオブジェクトであ
るとすることができるだけである。これらのクラスの各
々が異なる<printStudentInfo()>メソッドを定義するの
で、これらのメソッドのどれがループの各パスで起動さ
れるかを決定することは不可能である。これはすべて、
上書き導出の制御の下にある。

【００７９】次に「ＳＯＭユーザ・プログラム」につて
記述する。ユーザ・プログラムがどのようにプログラム
の中でこれらの４つのクラスを利用するかを理解するた
めに、以下のファイル<main.c>で１例を示す。この例で
は、ＳＯＭにおけるオブジェクトのインスタンス化およ
び作成と、メソッド起動の方法とを示す。

【００８０】 ＳＯＭユーザ・プログラムコード:<main.c> #include <student.h> #include <course.h> #include <graduate.h> #include <undgrad.h> main() { Course *course = CourseNew(); GraduateStudent *jane = GraduateStudentNew(); UnderGraduateStudent *mark = UnderGraduateStudentNew(); setUpCourse(course, "303", "Compilers", "Dr. David Johnson", 3, 15); _setUpGraduateStudent(jane,"423538","Jane Brown", "Code Optimization","Ph.D."); _setUpUnderGraduateStudent(mark,"399542", "Mark Smith", "12/17/92"); _addStudent(course, jane); _addStudent(course, mark); _printCourseInfo(course);} } クラスはメソッド<classNameNew()>によってインスタン
ス化され、各々知らされたクラスに関しＳＯＭによって
自動的に定義される。メソッド名の前に下線"_"を置く
ことによって、メソッドは起動される。第１のパラメー
タは、目標オブジェクトである。残りのパラメータは、
メソッドによって必要な付加情報を示す。実行時、ユー
ザ・プログラムは、下記のようなデータを出力する。

【００８１】303 Compilers（コンパイラ） Instructor Name （インストラクター名）:Dr. David J
ohnson Credit（単位数）= 3, Capacity（席数）= 15, Enrollm
ent（申込者数）= 2 Student List（学生リスト）: Id（学生番号 ） : 423538 Name （名前 ） : Jane Brown Type （タイプ） : Graduate（卒業生） Thesis （科目） : Code Optimization（コード
最適化） 学位 : Ph.D.（博士号） Id（番号） : 399542 Name （名前） : Mark Smith Type （タイプ） : UnderGraduate（卒業予定） Grad Date（卒業予定日）:12/17/92 ユーザ・プログラム出力データは、複数の<UnderGradua
te>および<GraduateStudent>を表示する種々の様式で動
作する上書き導出を例証している。<Course>は、複数<S
tudent>の配列を含み、どの<Student>も<printStudentI
nfo()>メソッドに応答することを知っている。しかし、
<UnderGraduate>が応答する<printStudentInfo()>メソ
ッドは、<GraduateStudent>が応答する<printStudentIn
fo()>メソッドとは異なっており、２つのメソッドは、
異なるデータを出力する。

【００８２】次に「ＳＯＭオブジェクト・モデル」につ
いて説明を行う。

【００８３】図２は、本発明に従う基本的ＳＯＭのデー
タ構造である。ＳＯＭは、コンピュータのランダム・ア
クセス・メモリ上で実行されることができるか、あるい
はコンピュータ・メモリへの読み取りや転送のためのフ
ロッピー・ディスクのようなコンピュータ読み取り可能
媒体上に記憶されることができる。ラベル２１０は、あ
る特定のオブジェクトに関する状態データ構造である。
ラベル２２０における第１のフルワードは、オブジェク
トのメソッド・プロシージャ・テーブル・ラベル２４０
のアドレスを含む。ラベル２３０をつけた状態データ構
造の残りは、オブジェクトに関連する付加情報を含む。
ラベル２４０をつけたメソッド・プロシージャ・テーブ
ルは、クラス・オブジェクト・データ構造のアドレス２
４５と特定のオブジェクトに関する種々のメソッドのア
ドレス２５０および２６０とを含む。２４５におけるア
ドレスは、クラス・オブジェクト・データ構造２４８を
ポイントする。このオブジェクトと同じクラスに属する
すべてのオブジェクトは、また、ラベル２４０で示され
るこのメソッド・プロシージャ・テーブルをポイントす
るアドレスを含む。オブジェクトによって継承されたど
のメソッドも、それが継承される先祖クラスのメソッド
・プロシージャ・テーブル（ラベル２４０）と同じメモ
リ上のオフセット値のメソッド・プロシージャ・アドレ
スを持つ。２つのメソッド・プロシージャに関する一連
の命令を含むコンピュータ・メモリのブロックのアドレ
スは、ラベル２５０と２６０で示される。ラベル２７０
および２８０は、ラベル２５０および２６０によって表
わされたアドレスによってポイントされた特定のメソッ
ド・プロシージャの一連の命令を含むコンピュータ・メ
モリの位置を表わす。

【００８４】ＳＯＭオブジェクト・モデルの大部分は、
基本的ＳＯＭサポートの一部である３つのクラスによっ
て実現される。要約すれば、これらのクラスは以下の通
り。

【００８５】SOMObject−このクラスは、すべてのＳＯ
Ｍクラスのルート・クラスである。いかなるクラスも、
SOMObjectの子孫でなければならない。すべてのクラス
がSOMObjectの子孫であるので、それらはSOMObjectによ
って定義されるメソッドをすべて継承し、従ってサポー
トする。ＳＯＭクラスのすべてのメソッドと同様にSOMO
bjectのメソッドは、SOMObjectの子孫であるクラスによ
って上書きされることができる。

【００８６】SOMClass−このクラスは、すべてのＳＯＭ
メタクラスに関するルート・メタクラスである。メタク
ラスは、そのインスタンスがクラス・オブジェクトであ
る１つのクラスである。SOMClassは、新しいクラス・オ
ブジェクトを作成することを可能にするメソッドを提供
する。

【００８７】SOMClassMgr−このクラスは、クラス・オ
ブジェクトを管理するＳＯＭに基づくプログラムにおけ
る唯一のオブジェクトを作成するために使われる。

【００８８】３つのＳＯＭ基底クラスは、以下のように
定義される。 １. SOMObject：これは、ＳＯＭルート・クラスであ
り、すべてのＳＯＭクラスは、<SOMObject>の子孫でな
ければならない。<SOMObject>はインスタンス・データ
を持たないので、その子孫であることに負担はかからな
い。SOMObjectは、以下のメソッドを持つ: メソッド:somInit パラメータ: somSelf 戻り値: void 説明: <self>を初期化する。<SOMObject>のインスタン
スがインスタンス・データを持たないので、初期状態に
する何も存在しない。このメソッドを呼び出す必要はな
い。これは、初期状態設定を必要とするサブクラス間の
整合性を保つために提供される。オブジェクト作成（例
えば、<somNew>による）の副作用として、<somInit>は
自動的に呼び出される。この副作用が必要とされない場
合は、<somInit>を起動しない（ユーザ作成メタクラス
における）別のバージョンの<somNew>を用いることがで
きる。このメソッドを上書きする時は、初期化を行うた
め、このメソッドの親クラス・バージョンを事前に呼び
出されなければならない。

【００８９】メソッド: somUninit パラメータ:somSelf 戻り値:void 説明: selfの初期設定を解く。<SOMObject>のインスタ
ンスがインスタンス・データを持たないので、初期設定
を解く対象は何も存在しない。このメソッドは呼び出さ
れてはならない。これは、初期状態解除を必要とするサ
ブクラス間の整合性を保つために提供される。このメソ
ッドは、動的に割り当てられた記憶装置のようなものを
きれいにするために使われる。しかし、このメソッド
は、オブジェクト・インスタンスに割り当てられた実際
の記憶装置を解放しない。このメソッドは、動的に割り
当てられたオブジェクトに関係付けられた記憶装置を解
放する<somFree>を補うものとして提供される。通常、<
somFree>を呼び出す時は常に<somUninit>を呼び出す。
しかし、<somRenew>（<SOMClass>の定義参照）がオブジ
ェクト・インスタンスを作成するために使われた場合
は、<somFree>は呼び出されず、<somUninit>が明示的に
呼び出されなければならない。

【００９０】このメソッドを上書きする時、このメソッ
ドの親クラスのバージョンは、常に初期状態解除の後に
呼び出されなけれならない。

【００９１】メソッド:somFree パラメータ:somSelf 戻り値:void 説明: <self>が<somNew>（または<somNew>を使用した別
のクラス・メソッド）によって作成されたと仮定して、
<self>に関係付けられている記憶装置を解放する。これ
以降<self>に対する参照は行われない。記憶装置を解放
する前に<self>に関する<somUninit>を呼ぶ。このメソ
ッドは、<somNew>（<somClass>の定義参照）によって作
成されるオブジェクトに関してのみ呼び出されねばなら
ず、<somRenew>によって作成されたオブジェクトに関し
ては決して呼び出しを行ってはならない。このメソッド
を上書きすることは、必要ではない。

【００９２】メソッド:somGetClassName パラメータ:somSelf 戻り値:Zstring 説明:（NULLで終わる文字列である）このオブジェクト
のクラスの名前へのポインタを戻す。名前を受け取るた
めクラス・オブジェクトのメソッド<somGetName>を起動
するだけであるので、このメソッドに上書きすることは
必要ではない。

【００９３】メソッド:somGetClass パラメータ:somSelf 戻り値:SOMClass 説明:このオブジェクトのクラス・オブ ジェクトを戻
す。

【００９４】メソッド:somGetSize パラメータ:somSelf 戻り値:integer4 説明:このインスタンスのサイズをバイト単位で戻す。

【００９５】メソッド:somRespondsTo パラメータ:somSelf, somId Mid 戻り値:int 説明:識別されたメソッドがこのオブジェクトのクラス
によってサポートされるならば、１（真）を戻し、さも
なければ、０（偽）を戻す。

【００９６】メソッド:somIsA パラメータ:somSelf, SOMClass *Aclassobj 戻り値:int 説明: <self>のクラスが<Aclassobj>の子孫クラスであ
れば、１（真）を戻し、さもなければ、０（偽）を戻
す。注: クラス・オブジェクトは、このメソッドの目的
のためにそれ自身の子孫であるとみなされる。

【００９７】メソッド:somIsInstanceOf パラメータ:somSelf, SOMClass *Aclassobj 戻り値:int 説明: <self>が指定された<Aclassobj>のインスタンス
であるならば、１（真）を戻し、さもなければ０（偽）
を戻す 。

【００９８】SOMObjectメソッドは、動的オブジェクト
・モデルをサポートする。これらのメソッドは、非常に
動的な領域がＳＯＭオブジェクト・プロトコル境界に連
結することを容易にさせる。これらのメソッドは、適切
なメソッド・プロシージャを決定し、次に、指定された
引数(arguments)を用いてそれを呼び出す。このクラス
で与えられるこれらのメソッドの実現の省略時解釈は、
単にその名前によってそのメソッドを探索し、それを呼
び出す。しかし、その他のクラスは、それらが望むいか
なる探索の形態を実行するように選択できる。例えば、
これらのメソッドの実現の１つの方法として、メソッド
導出のCLOS形態を使用することが可能である。そうする
ことができる領域に関して、そのメソッドを直接起動す
ることは、ディスパッチ・メソッドを経由する場合に比
べて、一般的に非常に速い。しかし、すべてのメソッド
は、ディスパッチ・メソッドを通してアクセスすること
が可能である。ＳＯＭは、呼出し元が決してメソッド導
出をする必要がないように、これらのメソッド呼び出し
を包含する小規模の外部手続きを提供する。

【００９９】これらのメソッドは、可変長引数リストを
確保するために宣言されるが、すべてのそのようなメソ
ッドと同様に、ＳＯＭオブジェクト・プロトコル境界
は、引数リストの可変部分が、メソッドが実際に起動さ
れる前に、可変引数リストに関する標準的、プラットホ
ーム特有のデータ構造にアセンブルされることを必要と
する。これは、実行時に引数リストを構築することを必
要とするドメインにおいて非常に役立つことができる。
それらドメインは、呼び出しのため構築された引数を通
常の形式にしなくてもメソッドを起動することができ
る。そのような操作がほとんどの高水準言語において通
常不可能であり、プラットホーム特有のアセンブラ言語
ルーチンを使用しなければならないので、この点は役に
立つ。

【０１００】異なるメソッドは、異なる戻り値形に関し
て定義される。これは、戻り値を運ぶために追加のパラ
メータが必要となる場合にいくつかのドメインで発生す
るメモリ管理問題を回避する。ＳＯＭは、以下に示され
る４つのファミリの戻り値だけをサポートする。（例え
ばintegerのような）あるファミリの範囲内で、ＳＯＭ
は最大のメンバのみをサポートする 。

【０１０１】メソッド:somDispatchV パラメータ:somSelf, somId methodId, somId descript
or, ... 戻り値:void 説明: 値を戻さない。

【０１０２】メソッド:somDispatchL パラメータ:somSelf, somId metodId, somId descripto
r 戻り値:integer4 説明: 整数データが戻される普通の方法で、４バイト値
を戻す。この４バイト値は、もちろん、整数以外の数値
でもよい。

【０１０３】メソッド:somDispatchA パラメータ:somSelf, somId methodId, somId descript
or 戻り値:void 説明: そのようなデータが戻される普通の方法で、デー
タ構造アドレスを戻す。

【０１０４】メソッド:somDispatchD パラメータ:somSelf, somId methodId. somId descript
or 戻り値: float8 説明: 浮動小数点値が返される普通の方法で、８バイト
数値を戻す。

【０１０５】「開発をサポートするSOMObjectメソッ
ド」について次に説明を行う。このグループのメソッド
は、サポート・プログラム開発を支援するために提供さ
れる。殆どの開発文脈は開発するのが容易であるとわか
るような方法で定義が行われてきた。しかし、それらの
文脈のいくつかは、その入出力機構をカスタマイズする
必要がある。非常にポータブルな方法でこのカスタム化
を可能にすることを試みたが、すべての文脈が関数パラ
メータの受け渡しを必要とするため、直接的なカスタム
化操作を実行すことはできない。以下記述のアプローチ
は、プラットホーム中立的柔軟性を可能にすることがで
きるため採用した。また、下記アプローチにおいて、ど
の開発サポート提供者も、その特定の開発システム環境
に必要なカスタム化を提供することが合理的であると見
なすであろう。

【０１０６】選択されたアプローチは、文字出力ルーチ
ンに依存する。外部変数<SOMOutCharRoutine>は、この
ルーチンをポイントする。ＳＯＭシステム環境は、標準
出力ストリームに従っているので、ほとんどの開発シス
テム環境で動くようにこのルーチンの実現を図ってい
る。しかしながら、開発文脈は、新しい値を<SOMOutCha
rRoutine>に割当てることができ、出力処理をそれによ
って再定義することができる。ＳＯＭは、この割当てを
行うための特別のサポートを提供しない。

【０１０７】メソッド:somPrintSelf パラメータ:somSelf 戻り値:SOMAny 説明:このオブジェクトに関する識別情報をもつ短い文
字列を書くために<SOMOutCharRoutine>を使う。実現の
省略時解釈は、オブジェクトのクラス名とそのメモリ・
アドレスを与えるだけである:<self>が、戻される。

【０１０８】メソッド:somDumpSelf パラメータ:somSelf, int level 戻り:void 説明: このオブジェクトの詳細な説明とその現在状態を
書き込むために<SOMOutCharRoutine>を使う。複合オブ
ジェクトを記述するために、<level>はネストのレベル
を示す。それは、ゼロまたはそれ以上である。記述中の
すべての行の先頭に、<2*level>のブランクが入れられ
る。このルーチンは、クラスのような、全体としてのオ
ブジェクトに関わるデータを書くだけで、オブジェクト
の現在状態を記述するために<somDumpSelfInt>を使う。
このアプローチは、複合オブジェクトの読みやすい説明
を作成することを可能にする。一般に、このメソッドを
上書きすることは必要でない。もしも上書きされるなら
ば、一般的には完全に置き換えられなければならない。

【０１０９】メソッド:somDumpSelfInt パラメータ:somSelf,int level 戻り値:void 説明: このオブジェクトの現在状態を書くために<SOMOu
tCharRoutine>を使う。一般的には、このメソッドは上
書きされる。これを上書きする時は、このメソッドの親
クラス形式を呼び出すことから始め、次に、ユーザ・プ
ログラムのクラス・インスタンスのデータの記述を書き
込む。このようにして、ルート先祖クラスから特定クラ
スへ行くすべてのオブジェクトのインスタンスのデータ
の記述ができあがる。 ２. SOMClass：これは、すべての他のメタクラスのルー
トであるプリミティブＳＯＭメタクラスである。すなわ
ち、このクラスのインスタンスは、クラス・オブジェク
トである。ＳＯＭシステム環境がつくられる時、外部名
<SOMClassClassData.classObject>をもつこのクラスの
１つインスタンスが作成される。このクラス・オブジェ
クトは、それがそれ自身のクラス・オブジェクトである
故に、ユニークである。すなわち、SOMClassClassData.
classObject == _somGetClass(SOMClassClassData.clas
sObject)である。このクラスは、ＳＯＭオブジェクトの
新しいインスタンスを作成するために使われるsomNewお
よびsomRenewメソッドを導入する。<SOMClassClassDat
a.classObject>に適用されるsomNewメソッドは、次に特
定の新しいクラスになるために初期化される新しいクラ
ス・オブジェクトを生成する。SOMClassは、いかなるＳ
ＯＭクラスと同様に、サブクラス化されることができ
る。SOMClassのサブクラスは、新しいメタクラスであっ
て、<SOMClassClassData.classObject>によって生成さ
れるものと異なる実現をもつクラス・オブジェクトを生
成することができる。

【０１１０】SOMClassは、SOMObjectの子孫である。

【０１１１】SOMClassは、以下のメソッドを定義する。

【０１１２】メソッド:somNew パラメータ:somSelf 戻り値: SOMAny * 説明: このクラスのインスタンスを作成する。<SOMClas
sClassData.classObject>または他のメタクラス・オブ
ジェクトに適用される時、これは新しいクラス・オブジ
ェクトを生成する；通常のクラス・オブジェクトに適用
される時、これはそのクラスのインスタンスを生成す
る。

【０１１３】メソッド:somRenew パラメータ:somSelf, SOMAny *obj 戻り値:SOMAny * 説明: このクラスのインスタンスを作成するが、オブジ
ェクトのための新しい領域を割り当てるよりむしろ<obj
>によってポイントされる領域を使用する。注:<obj> が
十分な領域をポイントすることを保証するテストは行わ
れない。<obj>が戻されるが、それは有効な、初期化さ
れたオブジェクトへのポインタである。

【０１１４】メソッド:somInitClass パラメータ:somSelf, bool inheritVars, Zstring clas
sName, SOMAny *parentClass, integer4 instanceSize, int maxStatic
Methods, integer4 majorVersion, integer4 minorVersion 戻り値:void 説明: <self>を初期化する。 <inheritVars>は、伝統的サブクラス化継承が要求され
るならば、真であり、または、<self>を初期化するため
に、抽象的継承が使われることになっているならば、偽
である。<parentClass>は、このクラスの親（または親
クラス）であり、それが省略時解釈としてのSOMObject
（実際にはSOMObjectのためのクラス・オブジェクトで
あるSOMObjectClassData.classObject ）である場合、
NULL (ヌル）であるかもしれない。もしも親クラスが指
定されるならば、そのクラス・オブジェクトへのポイン
タが必要とされるので、それは事前に作成されていなけ
ればならない。<instanceSize>は、単にこのクラスのた
めに必要とされる領域であり、親クラスの（もしあれ
ば）領域要求を考慮する必要はない。<maxStaticMethod
s>は、単にこのクラスによって定義される静的メソッド
であり、たとえそれらがこのクラスにおいて上書きされ
るとしても、親クラスのメソッドを考慮する必要はな
い。

【０１１５】<majorVersion>はクラス定義のこの実現に
関するメジャー・バージョン番号を示し、<minorVersio
n>は、マイナー・バージョン番号を示す。

【０１１６】メソッド:somClassReady パラメータ:somSelf 戻り値:void 説明: クラスに対する静的初期設定のすべてが終了した
時、このメソッドは、起動される。省略時解釈の実現
は、単にSOMClassMgrによって新たに構築されたクラス
を登録する。メタクラスが、クラス構築シーケンスを変
更するためにこのメソッドを上書きすることもある。

【０１１７】メソッド:somGetName パラメータ:somSelf 戻り値:Zstring 説明: NULLで終了する文字列として、このオブジェクト
のクラス名を戻す。

【０１１８】メソッド:somGetParent パラメータ:somSelf 戻り値:SOMClass * 説明: もし１つ存在すればselfの親クラスを、さもなけ
ればNULL（ヌル）を戻す。

【０１１９】メソッド:somGetClassData パラメータ:somSelf 戻り値:somClassDataStructure * 説明: 静的<className>ClassData構造へのポインタを戻
す。

【０１２０】メソッド:somSetClassData パラメータ:somSelf, somClassDataStructure *cds 戻り値:void 説明: 静的<className>ClassData構造へのクラスのポイ
ンタをセットする。

【０１２１】メソッド:somDescendedErom パラメータ:somSelf, SOMClass *Aclassobj 戻り値:int 説明:<self>が<Aclassobj>の子孫クラスであれば、1
（真）を、さもなければ０ （誤）を戻す。注:クラス・
オブジェクトは、このメソッドの目的のためにそれ 自
身子孫となっているとみなされる。

【０１２２】メソッド:somCheckVersion パラメータ:somSelf, integer4 majorversion, integer
4 minorVersion 戻り値:int 説明: このクラスの実現が指定されたバージョン番号と
互換性を持つならば、1（真）を、さもなければ０
（偽）を戻す。実現は、<minorVersion>に等しいかそれ
より大きい同じメジャー・バージョン番号とマイナー・
バージョン番号を持っていれば、指定されたバージョン
番号と互換性を持っている。メジャーとマイナーのバー
ジョン番号のペア（0,O）は、どのバージョンとも合致
するものとみなされる。このメソッドは、通常、クラス
・オブジェクトの生成直後に、動的にロードされたクラ
ス定義が使用している適用業務と互換性を持つことを検
証するために、呼び出される。

【０１２３】メソッド:somFindMethod パラメータ:somSelf, somid methodid, somMethodProc
**m 戻り値:int 説明: このクラスに関する<methodId>と関連するメソッ
ド・プロシージャを見つけ、それに<m>をセットする。
メソッド・プロシージャが直接呼ばれることができれる
時、1（真）が戻され、メソッド・プロシージャがディ
スパッチ関数である時、0（偽）が戻される。もしもク
ラスが指定されたメソッドをサポートしていないなら
ば、<m>は NULL （ヌル）にセットされ、戻り値は無意
味となる。ディスパッチ関数を戻すことは、クラスが指
定されたメソッドをサポートすることを保証しない。す
なわち、ディスパッチは、失敗する場合もある。

【０１２４】メソッド:somFindMethodOk パラメータ:somSelf, somid methodId, SomMethodProc
**m 戻り値:int 説明: メソッドがサポートされていない場合、エラーと
なって、実行が停止させられる点を除いて、<somFindMe
thod>と同じである。

【０１２５】メソッド:somFindSMethod パラメータ:somSelf, somId methodId 戻り値:somMethodProc * 説明: このクラスに関し定義された静的メソッドでなけ
ればならない指示されたメソッドを見つけ、そのメソッ
ド・プロシージャへのポインタを戻す。メソッドが、こ
のクラスに関して（静的メソッドとして、あるいは、全
く）定義されていない場合、NULL （ヌル）ポインタが
返される。

【０１２６】メソッド:somFindSMethodOk パラメータ:somSelf, somId methodId 戻り値:somMethodProc * 説明: このクラスに関しメソッドが定義されていない場
合エラーとなる点を除いて、<somFindSMethod> と同じ
である。

【０１２７】メソッド:somSupportsMethod パラメータ:somSelf, somid Mid 戻り値:int 説明: 指示されたメソッドがこのクラスによってサポー
トされていれば、1（真）を、さもなければ０（偽）を
戻す。

【０１２８】メソッド:somGetNumMethods パラメータ:somSelf 戻り値:int 説明:（静的、動的両方の）継承されたメソッドを含
め、このクラスによって現在サポートされているメソッ
ドの数を戻す。

【０１２９】メソッド:somGetInstanceSize パラメータ:somSelf 戻り値:integer4 説明: <self>のインスタンスの全体サイズを戻す。<sel
f>のすべてのインスタンスは、同じサイズを持つ。

【０１３０】メソッド:somGetInstanceOffset パラメータ:somSelf 戻り値:integer4 説明: このクラスに属するインスタンス・データに関
しこのオブジェクトの本体部分におけるオフセット値を
戻す。

【０１３１】メソッド:somGetInstancePartSize パラメータ:somSelf 戻り値:integer4 説明: このクラスのために必要なインスタンス・データ
のサイズ（バイト単位）を戻す。これは、このクラスの
先祖または子孫クラスのために必要なインスタンス・デ
ータ領域を含まない。

【０１３２】メソッド:somGetNumStaticMethods パラメータ:somSelf 戻り値:int 説明: このクラスが持つ静的メソッドの数を戻す。これ
は、そのメソッド・テーブルを初期化する際に、子クラ
スによって使われる。

【０１３３】メソッド:somGetPClsMtab パラメータ:somSelf 戻り値:somMethodTab * 説明: このクラスの親クラスのメソッド・テーブルへの
ポインタを戻す。このクラスがルート・クラス（SOMObj
ect）であれば、NULL（ヌル）が戻される。

【０１３４】メソッド:パラメータ: somSelf戻り値:somMethodTab * 説明:このクラスのメソッド・テーブルへのポインタを
戻す。

【０１３５】メソッド:somAddStaticMethod パラメータ:somSelf, somId methodId, somId methodDe
scriptor,somMethodProc *method, somMethodProc *red
ispatchstub,somMethodProc *applyStub 戻り値:somMOffset 説明: 指示されたメソッドを加え／上書きし、このメソ
ッド名に関しオフセット値をクラス・データ構造でセッ
トするために使われなければならない値を戻す。<metho
dDescriptor>は、SOMObjectクラス定義において定義さ
れた<somcGetNthMethodInfo>で記述されているように、
このメソッドに対する呼出しシークエンスを記述するso
mIdである。<method>は、このメソッドのための実際の
メソッド・プロシージャである。<redispatchStub>は、
このクラスのディスパッチ関数の１つへメソッドを再デ
ィスパッチする<method>と同じ呼出しシークエンスをも
つプロシージャである。<applyStub>は、標準的可変引
数リスト・データ構造をとり、データ構造から派生され
た引数をもつ<method>を呼び出すことによって、それを
その目標オブジェクトに適用するプロシージャである。
その呼出しシーケンスは、SOMobjectで定義されたディ
スパッチ・メソッドの呼出シーケンスと同じである。こ
のスタッブは、いくつかのクラスで使われるディスパッ
チ・メソッドのサポートで使われる。ディスパッチ関数
のような関数を必要としない場合、このパラメータは、
null（ヌル）とすることがある。

【０１３６】メソッド:somOverrideSMethod パラメータ:somSelf, somId methodId, somMethodProc
*method 戻り値:void 説明: クラスの親クラスがすでにこのメソッドをサポー
トしていることがわかる場合、このメソッドが、<somAd
dStaticMethod>または<somAddDynamicMethod>の代わり
に使われる。この呼び出しは、他の呼び出しが必要とし
ているメソッド記述子（ descriptor ）およびスタッブ
（stub）・メソッドを必要としない。

【０１３７】メソッド:somGetMethodOffset パラメータ:somSelf, somId methodId 戻り値:integer4 説明:これが静的メソッドであると仮定して、メソッド
・プロシージャ・テーブルにおける指定されたメソッド
のオフセット値を戻す。そうでなければ、０を戻す。こ
の値は、このクラス・データ構造におけるオフセット値
をセットするために使われる。あるクラスがまさに継承
を行なうメソッドを定義するために使われる場合のみ、
これは必要である。

【０１３８】メソッド:somGetApplyStub パラメータ:omSelf, somId methodId 戻り値: somMethodProc 説明:指定されたメソッドと関連する適用スタッブを戻
す。メソッドがこのクラスによってサポートされていな
い場合、NULL（ヌル）が戻される。適用スタッブは、固
定的呼出シーケンス、すなわち、（SOMAny *self, somI
d methodId, somId descriptor, ap_list ap）で呼ばれ
るプロシージャである。上記で、<ap>は、メソッドに渡
されるべき実際の引数リストを含む可変引数データ構造
である。適用スタッブは、呼び出しをその関連メソッド
へ送り出し、次に、メソッドによって作成された結果を
戻す。

【０１３９】３. SOMClassMgr：SOMClassMgrは、SOMObj
ectの子孫である。

【０１４０】SOMObjectは、下記メソッドを定義する: メソッド:somFindClsInFile パラメータ:somSelf, somId classId, int majorVersio
n, int minorversion,Zstring file 戻す:SOMClass * 説明: 指定されたクラスに関するクラス・オブジェクト
を戻す。これは、結果として動的ローディングとなる。
クラスがすでに存在すれば、<file>は無視され、さもな
ければ、クラスをつきとめ、動的にロードするために使
用される。メジャーおよびマイナーの番号に対する０の
値は、バージョン・チェックをバイパスさせる。

【０１４１】メソッド:somFindClass パラメータ:somSelf, somId classId, int majorVersio
n, int minorVersion 戻り値:SOMClass * 説明: 指定されたクラスに関するクラス・オブジェクト
を戻す。これは、結果として動的ローディングとなる。
クラスのコードが格納されているファイルの名前を入手
するためsomLocateClassFilを使用し、次に、somFindCl
sInFileを使用する。

【０１４２】メソッド:somClassFromId パラメータ:somSelf, somId classId 戻り値:SOMClass * 説明:Idを用いて、クラス・オブジェクトを見つける。
クラスをロードしない。クラス・オブジェクトがまだ存
在しない場合、NULL（ヌル）を戻す。

【０１４３】メソッド:somRegisterClass パラメータ:somSelf, SOMClass *classObj 戻り値:void 説明: 指定されたクラスが導入されていることと、クラ
ス・オブジェクトがどこに存在するかをクラス・マネー
ジャ(Class Manager)に知らせる。

【０１４４】メソッド:somUnregisterClass パラメータ:somSelf, SOMClass *classObj 戻り値:int 説明: クラス・ファイルをアンロードし、ＳＯＭレジス
トリからクラスを取り除く。

【０１４５】メソッド:somLocateClassFile パラメータ:somSelf, BomId classId, int majorVersio
n, int minorVersion 戻り値:Zstring 説明: サブクラスによって与えられる実際の実現であ
る。省略時解釈実現は、ファイル名としてクラス名を戻
す。サブクラスは、ファイル名の派生を助けるためバー
ジョン番号情報（ version number info）を使用するこ
とができる。

【０１４６】メソッド:somLoadClassFile パラメータ:somSelf, somId classId, int majorVersio
n, int minorversion,Zstring file 戻り値:SOMClass * 説明:クラスのコードをロードし、クラス・オブジェク
トを初期化する。

【０１４７】メソッド:somUnloadClassFile パラメータ:somSelf, SOMClass *classObj 戻り値:int 説明:クラスのコードを解放し、クラス・オブジェクト
を破棄する。

【０１４８】メソッド:somGetInitFunction パラメータ:somSelf 戻り値:Zstring 説明: クラスのコード・ファイルにおける初期化関数の
名前を供給する。省略時解釈実現は、(*SOMClassInitFu
ncName)()を戻す。

【０１４９】メソッド:somMergeInto パラメータ:somSelf, SOMObject *targetObj 戻り値:void 説明: 受取手からのSOMClassMgrレジストリ情報を<targ
etObj>にマージする。メソッド<targetObj>は、SOMClas
sMgrのインスタンスまたはそのサブクラスの１つである
ことが必要とされる。この操作の終了時点で、<targetO
bj>は、代わりの受取手として機能することができる。
操作の終了時点で、新たに初期化解除された状態にある
受取手オブジェクトが解放される。このメソッドを上書
きするサブクラスが、オブジェクトのそれらの部分を同
様に転送し、最終的なステップとしてこのメソッドをそ
れらの親に渡す。受け取りオブジェクトが広域変数SOMC
lassMgrObjectからポイントされた明確なインスタンス
であるならば、SOMCLassMgrObjectは<targetObj>をポイ
ントするために再割り当てされる。

【０１５０】以上、３つの基本的ＳＯＭクラスについて
説明を行った。次に、「オブジェクト名の管理」につい
ての説明を行う。

【０１５１】あるクラスのためのメソッド各々に関しユ
ニークな外部名を必要とする過去のオブジェクト指向テ
クニックを改善するため、ＳＯＭは各クラス実現と関連
する特別なプロシージャを用いて、実行時にクラス・メ
ソッド・テーブルを初期化し、メソッド・オフセット値
をすべて外部的名前をもつ単一のクラス・データ構造に
集める。この改善は、外部変数の大きいリストを管理す
るという複雑さを減らし、ユニークな名を創造するとい
う問題を減らし、メモリ要求を減らし、生成された実行
モジュールのロード時間を減らす。

【０１５２】図３は、本発明に従うＳＯＭクラス・デー
タ構造である。ラベル３１０は、図２の２４８で示され
たクラス・オブジェクト・データ構造へのポインタを表
す。ラベル３２０は、図２のラベル２４０で説明された
メソッド・プロシージャ・テーブルへのオフセット値、
または、図２のラベル２３０のオブジェクトの状態デー
タ構造へのオフセット値を表わす。同様に、ラベル３３
０と３４０は、上記オフセット値に加えて、メソッド・
プロシージャ・テーブルへのオフセット値またはその状
態データ構造へのオフセット値を表わす。クラス・リリ
ース順序部で記述されるこのクラスまたはメソッドで最
初に定義されるが、そのクラスの先祖クラスの１つある
いは、このクラスによって定義されたパブリック・イン
スタンス変数によって定義される付加的メソッドに関し
て、このクラスと関連するオフセットを表わすクラス・
データ構造における同様のエントリがある（ラベル３５
０で省略記号と"N + 1" で示されている）。付加エント
リは、最初のエントリが図２のクラス・オブジェクト・
データ構造２４８へのポインタを表わすので、必要であ
る。

【０１５３】クラス・データ構造における値の順序は、
クラスＯＩＤＬファイルのリリース順序部における対応
するメソッドまたはパブリック・インスタンス変数名の
順序によって決定される。クラスにおいて定義されるが
リリース順序部で記述されないメソッドまたはパブリッ
ク・データ・メンバは、リリース順序部で記述されるメ
ソッドまたはメンバより後で、かつ、それらがクラスＯ
ＩＤＬファイルに出現する順序で順序付けられる。

【０１５４】次に、「オブジェクト・インターフェース
定義言語（Object Interface Definition Language、略
してＯＩＤＬ）」を説明する。

【０１５５】ＳＯＭは、いかなる言語に対するオブジェ
クト・サポートも提供される中立的情報セットとして、
言語に依存するオブジェクト定義を再定義する。中立的
情報セットは、オブジェクト・インターフェース定義言
語（Object Interface Definition Language、以下ＯＩ
ＤＬと略称する）と呼ばれる。ＳＯＭ ＯＩＤＬは、プ
ログラム言語がＳＯＭオブジェクトとその定義を使用
し、提供することを可能にする連結ファイルを生成する
ための基礎を提供する。各ＯＩＤＬファイルは、ＳＯＭ
オブジェクトの１つのクラスに対する完全なインターフ
ェースを定義する。

【０１５６】ＯＩＤＬファイルは、別々の言語に関し別
々の形式をとる。別々の形式によって、クラス実現ルー
チンが、追加の言語特有の情報を指定することを可能に
し、これによって、クラスを構築するためのサポートを
ＳＯＭ コンパイラが提供することを可能にする。それ
ら別々の形式の各々は、ユーザがクラスを使用するため
に知っていなければならない正確な情報を指定する共通
のコア言語を共有する。ＳＯＭコンパイラの機能の１つ
は、クラス定義の共通コア部分の抽出である。かくし
て、クラス実現ルーチンは、あるクラスに関する言語特
有なＯＩＤＬファイルを維持することができ、必要に応
じて言語中立的コア定義を作成するためＳＯＭコンパイ
ラを使うことができる。

【０１５７】本節は、Ｃ言語プログラミングをサポート
するため機能を拡張したＯＩＤＬを記述する。上述の通
り、ＯＩＤＬファイルは、言語特有または用途特有な一
組の連結ファイルを作成するためＳＯＭコンパイラによ
ってコンパイルされる。ＳＯＭコンパイラは、Ｃ言語の
ため以下の７つの異なるファイルを生成する:− クラス
を使用するプログラムに対するパブリック・ヘッダ・フ
ァイルクラスの使用には、クラスのインスタンス・オブ
ジェクトの作成と、インスタンス・オブジェクトに関す
るメソッドの呼び出しと、新しいクラスを生成するため
のクラスのサブクラス化とが含まれる。 − クラスが持つ可能性のあるプライベート・メソッド
に使用結合を提供するプライベート・ヘッダ・ファイル − クラスの実現をサポートするためマクロおよびその
他の材料を提供する実現ヘッダ・ファイル − クラス提供側が編集することができるクラス実現の
概要を提供する実現テンプレート − 言語中立的コア定義 − クラス・インターフェースのプライベート部分を含
むプライベート言語中立的コア・ファイル。 − OS／2 DLLの形でクラスを実装するために使われるこ
とができるOS／2 DEFファイル。

【０１５８】ＯＩＤＬファイルには、下記の「部」が含
まれる。 −Include部 −クラス部 −リリース順序部 −メタクラス部 −親クラス部 −パススル（受け渡し）部 −データ部 −メソッド部 上記各部について以下説明する。

【０１５９】1)Include 部：この部分は、ＯＩＤＬプリ
プロセッサに指示を行うInclude文を含む。これは、こ
のクラスの親クラスに関するクラス・インターフェース
定義と、クラスのメタクラスと、このクラスがそのクラ
スの１つ以上のプライベート・メソッドを上書きするす
べての先祖クラスに関するプライベート・インターフェ
ース・ファイルとをどこで見い出すべきかをコンパイラ
に伝える。

【０１６０】2)リリース順序部：このオプション部分
は、コンパイラに指定された順序で並べられた項目をも
つ一定の重要なデータ構造を構築することを強制するリ
リース順序文を含む。これは、クラス・インターフェー
スと実現が、このクラスを使用するプログラムが再コン
パイルを必要とせずに、進化することを可能にする。

【０１６１】リリース順序は、すべてのメソッド名とパ
ブリック・データ項目に当てはまる。あるメソッドまた
はパブリック・データ項目のリリース順序が指定されな
い場合、それは、省略時解釈で、ＯＩＤＬファイルにお
ける出現に基づく実現特有の順序になる。新しいパブリ
ック・データ項目またはメソッドの導入は、他のパブリ
ック・データ項目またはメソッドの省略時解釈の順序付
けを変更させる原因となるであろう；その結果、該クラ
スを使用するプログラムは、再コンパイルされねばなら
ない。

【０１６２】3)メタクラス部：この任意選択の部分は、
メタクラスを明示的に指定し、該クラスのメタクラスを
派生させる時、その名前と、オプションとして、このメ
タクラスが該クラスのための機能性を提供する理由の記
述とを与える。メタクラスが指定されるならば、その定
義は、"include" 部に含められなければならず、また、
該クラスのメタクラスを派生させる時、その定義は、考
慮に入れられる。いずれにせよ、このクラスのどの親に
も使用可能なデータに対するメソッドは新しいクラスで
も使用可能であることを保証するように、メタクラス
は、派生される。代替的方法として、単一の継承という
制約されたケースにおいて、すなわち、クラスが１つの
親クラスを持つという場合には、プログラマは、"クラ
ス"属性の使用によって（"データ"部と、"メソッド"部
との両方において）、派生されるメタクラスに関する要
求を含めることが可能である。これが行われると、"メ
タクラス"部は省略されなければならず、クラス変数と"
クラス"属性を使用して指定されるメソッドとを定義す
るメタクラスが派生される。この派生されたメタクラス
は、"暗示的メタクラス"と呼ばれ、<Name>が定義されて
いるクラスの名前であるとすれば<M-Name>という名前が
与えられる。この名前は、必要に応じて，その他のいく
つかのクラスのために明示的メタクラスとして使うこと
ができる。

【０１６３】4)親クラス部：この部分は、その名前と、
オプションとして、該クラスのインターフェースにおけ
る親クラスの役割の記述とを指定することによって、該
クラスの親クラスを指定する。

【０１６４】5)パススル（受け渡し）部：このオプショ
ン部分は、種々の連結ファイルへコンパイラによって受
け渡されるコード・ブロックを提供する。受け渡される
情報の内容は、コンパイラによって無視される。受け渡
し行に含まれるコメントも、変更なしに処理される。

【０１６５】6)データ部：このオプションの部分は、こ
のクラスに関するインスタンス変数をリストする。デー
タ部は、一般に、クラス・インターフェース定義（.CSC
ファイル）の言語特有バージョンにおいてのみ存在す
る。しかし、クラスがパブリック・インスタンス変数を
含む場合、クラス・インターフェース定義のパブリック
形式で存在しなければならない。ANSI Ｃ構文が、これ
らの変数を記述するために使われる。

【０１６６】7)メソッド部：このオプション部分は、こ
のクラスによってサポートされるメソッドをリストす
る。ＡＮＳＩ Ｃ関数プロトタイプ構文が、各メソッド
に対する呼出しシーケンスを定義するために使われる。

【０１６７】次に、「ＳＯＭ コンパイラ」について記
述する。ＳＯＭ コンパイラは、ＳＯＭクラスのＯＩＤ
Ｌソース定義を特定のプログラム言語に適する一組の結
合に翻訳する。OS／2 2.0 ツールキットによって供給さ
れるＳＯＭ コンパイラは、Ｃプログラム言語のための
結合の完全セットを生成する。

【０１６８】コンパイラは、２段階、すなわち、プレコ
ンパイルとエミッションとの２段階で動作する。第１の
プリコンパイラ段階は、ユーザ指定のクラス定義を読
み、分析し、クラス情報、コメントおよびパススル行を
含むバイナリ形式の中間出力ファイルを作成する。第２
段階では、１つ以上のエミッタ・プログラムが、適切な
言語連結ファイルを作成するために実行される。さらに
別の２つのプログラムが、ＳＯＭプリコンパイラ段階の
ためにプリプロセッサとして働く。これらのプログラム
のすべての順序付けおよび実行は、ＳＯＭ Compilerに
よって管理される。

【０１６９】ロード可能なモジュールを生成するため、
エミッタからの出力とクラスのメソッドに関するユーザ
提供のロジックとが、Ｃコンパイラによってコンパイル
され、OS／2 リンカによって連係される。ロード可能モ
ジュールは、完全独立なファイルにパッケージされる
か、あるいは、該クラスが多くのプログラムから使われ
ることができるように、DLLの形式で置かれる。

【０１７０】図４を参照すると、制御はブロック４００
から始まり、ブロック４０４へ直接進み、そこで、ＳＯ
Ｍ言語中立的オブジェクト・インターフェース定義４０
２（ＯＩＤＬ）がＳＯＭ ＯＩＤＬコンパイラ４０４に
入力される。ＳＯＭ ＯＩＤＬコンパイラは、目標言語
エミッタ４１０への入力としてコード生成プロセスを単
純化するためにＯＩＤＬのオブジェクト定義を解析して
中間標準形式４０６を作成する。言語エミッタ４１０
は、図３において説明されたクラス・データ構造を含む
言語結合４１４を生成する。制御は、ブロック４２０へ
進み、言語コンパイラが、言語適用業務４１６およびＳ
ＯＭ結合４１２からの追加入力を受け取る。言語コンパ
イラは、ユーザの選好に従ってＣ、FＯＲＴＲＡＮ、 Ｃ
ＯＢＯＬまたはその他のコンパイラが可能である。言語
コンパイラからの出力は、オブジェクト・ファイル４２
２であり、それは、引き続く実行のためＳＯＭ実行時ラ
イブラリによって連係編集される。

【０１７１】図５は、本発明に従うＳＯＭオブジェクト
を使用する適用業務の連係、ロードおよび実行を示すフ
ローチャートである。処理は、ブロック５００から始ま
り、ブロック５３０で、図４のラベル４２２で作成され
たＳＯＭオブジェクト５１０とＳＯＭ実行時ライブラリ
５２０との動的連係とロードを行う。次に、ブロック５
４０で、適用業務が始まり、ブロック５５０において示
される（図６から１０で詳細に説明される）必要なクラ
スとオブジェクトの生成を起動する。最後に、ブロック
５６０で適用業務は実行され、制御はブロック５７０で
終了する。

【０１７２】次に「オブジェクト指向プログラムに関す
るバージョン独立性」を説明する。ＳＯＭのオブジェク
ト指向プログラムに関するバージョン独立性という局面
は、オブジェクト指向適用業務の改善に一般的に関連
し、特にそれらを使用するオブジェクト定義ライブラリ
と適用業務の独立的発展から発生する問題の解決に関連
する。バージョン独立処理は、オブジェクト定義ライブ
ラリ（または呼び出されるオブジェクト・クラス・ライ
ブラリ）を使用する適用業務の実行可能バイナリ形式
を、オブジェクト定義の実現または仕様のある種の変更
から引き離す。このような変更は、長い間には、ライブ
ラリにおいて、発生するのが自然である。具体的には、
適用業務が実行される度毎にオブジェクト定義を動的に
ロードする適用業務の実行可能バイナリ形式を修正する
ことなく、オブジェクト定義に対する以下の変更を行う
ことが可能である。1）オブジェクト定義への新しいメ
ソッドの追加、2）子クラスからその親クラスへメソッ
ドに対する定義のポイントの移動、3）オブジェクト定
義に関連するプライベート・インスタンス・データの追
加、削除または変更、および、4）クラス階層への新し
いクラス定義の挿入、とである。

【０１７３】この処理は、以下に記述のいくつかのテク
ニックを使うプロセッサ・メモリ上のアルゴリズムの働
きによって遂行される。メソッドおよびインスタンス・
オフセット値は、適用業務バイナリ・イメージに含まれ
ない。Ｃ＋＋で定義されるような静的オブジェクト型モ
デルにおいては、メソッド・プロシージャ・テーブルへ
のオフセット値（整数）が、各特定のメソッド名に対す
るメソッド・プロシージャを選択するために使われる。
オフセット値は、メソッドが定義されるクラスのメソッ
ドの数および順序と、その先祖によって定義されたメソ
ッドの数とに依存する。

【０１７４】このアプローチは、非常に速い形式のメソ
ッド導出であるという利点を持つ。しかしながら、従来
技術のオブジェクト型モデルは、特定のオブジェクト・
クラスを使用した適用業務のバイナリ・イメージの中
に、これらのオフセット値を置いたため、 オフセット
値の変更が必要となる場合は必ず、適用業務を再コンパ
イルしなければならなかった。

【０１７５】ＳＯＭにおいては、メソッドに関係するオ
フセット値は、各クラス毎に、クラス・データ構造と呼
ばれる単一のデータ構造に集められる。このデータ構造
は、外部名を与えられ、その内容は適用業務において参
照される。各クラス・データ構造は、クラス・オブジェ
クトが初期化される時、適切なオフセット値を含むよう
に初期化される（図１０の説明と共に後節で詳細が記述
される）。従って、適用業務が実行される度毎に、すべ
てのオフセット値は、適用業務によって使用されるクラ
スの現在定義に基づいて再計算される。

【０１７６】クラス・データ構造で記憶された値への適
用業務バイナリ・イメージのいかなる参照も、オフセッ
ト値を含むという点留意されるべきである。しかし、こ
れらのオフセット値は、上に列挙された４種類の変更に
わたって、定数であることができる。なぜならば、クラ
ス・データ構造は、特定クラスで定義されるメソッドに
関するオフセット値を含むだけで、クラスによって継承
されるメソッドのオフセット値を保持するものではない
ためである。あるクラスに加えられた新しいメソッド
は、該クラスで既に定義されたメソッドのオフセット値
の位置を乱すことなく、クラス・データ構造の終わりに
追加されるオフセット値を持つことができる。

【０１７７】ＳＯＭオブジェクト・インターフェース定
義言語（ＯＩＤＬ）は、上述の「ＳＯＭオブジェクト・
モデル」で述べたリリース順序部を含む。ＯＩＤＬのリ
リース順序部によって、あるクラスにおいて既に定義さ
れたメソッドに対するメソッド・オフセット値の後に新
しいメソッド・オフセット値が加えられることをクラス
実現プログラムが確認することを可能にする。またＯＩ
ＤＬファイルのリリース順序部によって、クラスで定義
されたメソッドの１つが親クラスへ移される場合、１つ
のエントリがクラス・データ構造に保持される。このエ
ントリは、ＯＩＤＬコンパイラが図１０のクラス・デー
タ構造を初期化するロジックを追加するという単純な割
り当てステートメントによって、親オフセット値を基に
して初期化される。

【０１７８】同様の問題は、パブリック・インスタンス
・データにも起きる。適用業務のオブジェクト状態デー
タ構造の１つに含まれるパブリック・インスタンス変数
をアクセスする適用業務が、オブジェクトの状態データ
構造にオフセット値を用いてアクセスしなければならな
い。従来技術では、このオフセット値は、適用業務のバ
イナリ・イメージに含まれた。このテクニックが使われ
る場合、オブジェクトの先祖クラスのインスタンス・デ
ータの１つ以上のサイズ変更かまたは該オブジェクト自
身のインスタンス・データ形式の変更が必要となるの
で、適用業務のバイナリ・イメージは、オフセット値が
変わる時は必ず（再コンパイルによって）再生成されね
ばならない。

【０１７９】ＳＯＭでは、各パブリック・データ変数の
オフセット値をクラス・データ構造に入れることによっ
て、この問題は、解決される。図７と図１３で詳細に説
明される通り、クラス・オブジェクトが初期化される
時、適切なオフセット値を含むように、各クラス・デー
タ構造は初期化される。かくして、適用業務が実行され
る毎に、すべてのオフセット値が、適用業務によって使
用されるクラスの現在定義に基づいて再計算される。

【０１８０】次に、「適用業務のバイナリ・イメージか
らのオブジェクト状態データ構造サイズの除去」につい
て説明する。

【０１８１】オブジェクトの新しいインスタンスが作成
される時、コンピュータ・メモリの正確な大きさが、オ
ブジェクトの状態データ構造を保持するため割り当てら
れなければならない。従来技術においては、このメモリ
・ブロックのサイズは、適用業務のバイナリ・イメージ
に含まれた。このテクニックが使われると、オブジェク
トの状態データ構造のサイズが変わる時は必ず、適用業
務のバイナリ・イメージは、（再コンパイルによって）
再生成されねばならない。ＳＯＭにおいては、この値
は、オブジェクトのクラス・オブジェクトへの呼び出し
によって使用可能であり、従って、適用業務のバイナリ
・イメージに含まれる必要はない。

【０１８２】ＳＯＭの技術によって、適用業務のバイナ
リ・イメージを再生成することなしに、適用業務によっ
て使われるクラス定義に関する上記４つの変更が可能と
なる。

【０１８３】図６は、本発明に従う新しいＳＯＭクラス
の作成を記すフローチャートである。制御はブロック６
００から始まり、ブロック６１０で、バージョン番号の
正当性の検査が行われる。正しくないバージョン番号が
検出されると、メッセージが出力ブロック６１２で表示
され、制御はブロック６１４で終了する。正しいバージ
ョン番号が検出されると、ＳＯＭクラスが存在するかど
うかを判定するため、ブロック６２０で別のテストが実
行される。ＳＯＭクラスが存在すれば、処理はブロック
６２２で戻される。

【０１８４】ＳＯＭクラスが存在しない場合、ＳＯＭ実
行時環境が活動状態か否かを判定するためブロック６３
０でさらにテストが実行される。ＳＯＭ実行時環境が活
動状態でない場合、ＳＯＭ実行時環境が、ブロック６３
２で起動される。ＳＯＭシステム環境が初めから存在し
たかしなかったかいずれの場合でも、制御はブロック６
４０へ進み、ＳＯＭシステム環境のエラー・チェックが
行われる。エラーが発見されれば、該当するメッセージ
が、出力ブロック６４２で提示され、処理はブロック６
４４で終了する。エラーが発見されなければ、制御はブ
ロック６５０へ進み、派生メタクラスが準備される。次
に、図７で詳細に記述されるが、ブロック６５２でクラ
スが構築される。最後に、処理は、ブロック６６０で戻
される。

【０１８５】図７は、本発明に従う新しいＳＯＭクラス
構築の詳細を示すフローチャートである。制御はブロッ
ク７００で始まり、ブロック７１０において、図８で詳
述される総称的クラス・オブジェクトの作成が行われ
る。次に、新しい総称的クラスは、ブロック７２０で省
略時解釈の値に初期化される（図９で詳述される）。次
に、ブロック７３０で、特定の新しいクラスに対するイ
ンスタンス・データ・オフセット値が、初期化される。
制御は、ブロック７４０に進み、新しいクラスに関する
クラス・データ構造が、新しいクラスの各静的メソッド
を表わす値を割り当てることによって（図１０で詳述）
初期化される。

【０１８６】ブロック７５０、７６０、７７０で、親ク
ラスが設定され、クラス・データが初期化され、クラス
が登録される。これらのステップは、新しいクラス・デ
ータ構造の更新を必要とする（図２、１０および１３で
詳述）。最後に、制御はブロック７８０で戻される。

【０１８７】図８は、本発明に従って新しい総称的ＳＯ
Ｍクラス・オブジェクトを構築する詳細を示すフローチ
ャートである。制御はブロック８００で始まり、ブロッ
ク８１０において、メモリがオブジェクトのために割り
当てられる。次に、メモリが割り当てられたかどうか判
定するテストがブロック８２０で実行される。エラーが
検出されると、該当するエラー・メッセージが出力ブロ
ック８３０で表示され、処理はブロック８４０で終了す
る。エラーが発見されなければ、オブジェクトの省略時
解釈値がブロック８５０でセットされ、制御はブロック
８６０で戻される。

【０１８８】図９は、本発明に従って新しいＳＯＭクラ
ス・オブジェクトを初期化する詳細を示すフローチャー
トである。制御はブロック９００で始まり、ブロック９
１０に進んで、新しいＳＯＭクラス・オブジェクトの親
クラスが存在するかを検出するテストが実行される。も
しも親クラスが存在すれば、親クラスはブロック９１２
で初期化される。一旦親クラスが初期化されると、該ク
ラス名に対するメモリがブロック９２０で割り当てられ
る。次に、ブロック９３０で、新しいＳＯＭクラス・オ
ブジェクトの親クラスが存在するかを検出するテストが
再び実行される。

【０１８９】親クラスが存在しなければ、ブロック９３
２で示されるように、初期の変数はゼロにセットされ、
制御はブロック９４０に渡る。親クラスが存在すれば、
ブロック９４０で、継承が必要とされるかを決めるため
にテストが実行される。もしも必要とされなければ、オ
フセット値がゼロに設定され、制御はブロック９５０へ
渡る。もしも継承が要求されていれば、制御はブロック
９４４に進み、データ・オフセット値は親継承サイズに
セットされる。ブロック９５０で静的メソッドが計算さ
れ、ブロック９６０でメソッド・テーブルのサイズが計
算され、ブロック９６２でメソッド・テーブルに関する
データ構造が割り当てられ、ブロック９６４で、メソッ
ド・テーブルのエントリが初期化され、ブロック９６６
で、変数が継承されるかどうかを決めるためテストが実
行される。もしも変数が継承されるならば、ブロック９
６８で親メソッド・テーブルのエントリが省略時解釈の
エントリ上にコピーされる。しかし、変数が継承されな
いならば、ブロック９７０で、クラスに対するバージョ
ン番号がセットされ、ブロック９８０でエラー処理が実
行される。もしもエラーが発見されれば、該当するメッ
セージが出力ブロック９８２で表示され、処理はブロッ
ク９８４で終わる。もしもエラーが発見されなければ、
制御は、ブロック９９０で戻される。

【０１９０】図１０は、本発明に従って、オフセット値
をもつＳＯＭクラス・データ構造を初期化する詳細を示
すフローチャートである。制御は、ブロック１０００で
始まり、ブロック１０１０においてループが始まり、次
の静的メソッドを獲得する。ブロック１０２０で、新し
いメソッドＩＤが、ＳＯＭ実行時環境とともに登録され
る。次に、ブロック１０３０で、該メソッドが親クラス
において既に登録されたかどうかを判定するテストが実
行される。もしメソッドが登録されていれば、ブロック
１０３２で、メソッド・オフセット値は上書きされ、制
御はブロック１０７０へ渡る。

【０１９１】メソッドが親クラスによって登録されてい
ないならば、ブロック１０４０で、メソッドが現在クラ
スで定義されているかを判定するテストが実行される。
メソッドが定義されていれば、ブロック１０４２で、既
存のオフセット値が使われ、制御はブロック１０７０に
渡される。メソッドが定義されてなければ、ブロック１
０５０と１０６０で、メモリが割り当てられ、値は初期
化される。ブロック１０６０で、継承された静的メソッ
ドの数を該クラスによって現在までに処理された継承静
的メソッドの数に加えることによって、オフセット値が
計算される。エラー処理がブロック１０７０で実行さ
れ、エラーが検出されれば、該当するメッセージが出力
ブロック１０７２で表示され、処理はブロック１０７４
で終わる。エラー処理が完了されたあと、もうひとつの
テストがブロック１０８０で実行され、さらに追加メソ
ッド処理が必要かどうかが判定される。追加メソッドが
あれば、制御は、ブロック１０１０へ渡され、ループの
次の繰返しが行われる。さもなければ、制御はブロック
１０９０で戻される。

【０１９２】次に、「オブジェクト指向プログラミング
における陰の親クラス」と呼ばれる、置き換え親クラス
の動的挿入を行う論理を記述する。この処理は、実行の
間に動的に変えられる親クラスのうちのどの親クラスを
特定クラスに連係するのかを静的にコンパイルされる定
義に含めることを可能にする。静的にコンパイルされる
クラス階層へ新しい親クラスを挿入することを可能とす
ることによって、コードがバイナリ形式となった後、既
存のコードを維持し、改良するための柔軟性が増加す
る。これはまた、この結果が再コンパイルせずに達成さ
れるので、ソース・コード等にアクセスせずにコードを
カスタマイズできる新しい自由度を提供する。

【０１９３】従来技術のシステムでは、静的に連係する
派生クラスとその親クラスに関連する固有の制限があ
る。これらの制限には、派生オブジェクト状態データ構
造のサイズの計算、派生メソッド・プロシージャ・テー
ブルの初期化、および、派生クラスのメソッド内から親
クラスのメソッドへのアクセス（親クラス導出と呼ばれ
る）不可が含まれる。

【０１９４】ＳＯＭオブジェクト型モデルは、親クラス
・オブジェクトを通してすべての親クラス情報を実行時
に使用可能とすることによって、これらの制限を取り除
く。かくして、派生クラス実現が、親クラス状態データ
構造のサイズ関する情報、親クラスのメソッド・プロシ
ージャのアドレス、あるいは、（親クラス導出をサポー
トするため）親クラスのメソッド・プロシージャ・テー
ブルへのアクセスを必要とする時、親クラス・オブジェ
クトから情報を得るための適切な呼び出しが出される。
この情報を獲得する詳細な処理が図７、８、９および１
０で示される。

【０１９５】ＳＯＭは、あらゆるＳＯＭプロセスについ
てクラス・マネージャを導入する。クラス・マネージャ
は、クラスのレジストリ（登録台帳）を保持する責任を
持つ。ＳＯＭコンパイラによって生成されるクラス構築
コードは、子クラス・オブジェクトが作成される時はい
つでも、クラス・マネージャと協力して、クラスとその
親クラスとの間の関係を確立する。ＳＯＭクラス・マネ
ージャは、その他のＳＯＭクラスと同様に、サブクラス
化されることができるクラス・インスタンスである。
派生クラスは、ＳＯＭクラス・マネージャ・オブジェク
トに対する呼び出しを行うことによって、その親クラス
・オブジェクトへの接続を確立する。代替クラス実現を
オリジナルのクラス実現に替えたい適用業務設計者は、
下記のステップをとる。

【０１９６】１）クラス名を基にクラス・オブジェクト
を決定するための適用業務固有の規則を提供するSOMCla
ssMgrをサブクラス化する（すなわちsomClassFromId、s
omFindClassおよびsomFindClsInFileの実現を変更す
る）。

【０１９７】これを行う単純で有益な方法は、既存のク
ラス名の下に影のクラス・オブジェクトを登録し、次
に、somClassFromId、somFindClassまたはsomFindClsIn
Fileへの呼び出し（この場合陰の名前が指定される）に
おいて、呼出し適用業務へ影のクラス・オブジェクトを
戻すメソッドを追加することである。

【０１９８】２）陰になる親クラス・オブジェクトを持
つべき派生クラス・オブジェクトを作成する前に、（上
記ステップ１の記述のように）新しいクラス・マネージ
ャ・クラス・インスタンスを作成し、（somMergeIntoメ
ソッドを用いて）既存のSOMClassMgrインスタンスか
ら、それを初期化し、次に、ＳＯＭ 実行時に既存のSOM
ClassMgrインスタンスのアドレスを上書きすることによ
って既存のSOMClassMgrインスタンスを新しいクラス・
マネージャ・インスタンスに置き換える。

【０１９９】３）陰になる親クラス・オブジェクトを持
つべき派生クラス・オブジェクトを作成する前に、適用
業務指定のクラス・マネージャ・オブジェクトの機能を
使用して影のクラス・オブジェクトを登録する。

【０２００】上記の３つのステップが完了した後、派生
クラス・オブジェクトを作成することができる。それら
は、適切な影の親クラス・オブジェクトに連係される。
図１１で示されているように、クラス・オブジェクトを
初期化し、その親クラス・オブジェクトに連係するため
に特別の論理を用いる。この論理は、以下の２つの基本
ステップから成る。

【０２０１】１）第１に、静的に既知の親クラス・オブ
ジェクトが作成されたことを確認するための呼び出しが
行われる。これは、２つの重要な目的を適える。

【０２０２】(a) それは、静的に既知の親クラス定義の
バイナリ・イメージに対する静的参照を作成し、これに
よって、親クラス実現が適用業務のバイナリ・イメージ
に連係されることを保証する。(b)それは、少なくとも
静的に既知の親クラス・オブジェクトが、次のステップ
の前に、ＳＯＭクラス・マネージャ・オブジェクトとと
もに登録されたことを保証する。

【０２０３】静的に既知の親クラス・オブジェクトが
（例えば、上記陰の親クラス処理ステップを行う適用業
務によって）既に作成されていれば、２度目の試みは無
視される。

【０２０４】２）第２に、派生クラスの親クラスの名に
基づき該当するクラス・オブジェクトのアドレスを検索
するために、ＳＯＭクラス・マネージャ・オブジェクト
に対する呼び出しが行われる。陰の親クラス処理が既に
行われていれば、この呼び出しは、影のクラス・オブジ
ェクトを戻す。

【０２０５】上記のテクニックとメカニズムの組合せに
よって、派生クラスのバイナリ・イメージは、派生クラ
スが親クラス・データを引き出すために使用するクラス
・オブジェクトのクラスそのものに依存することから解
放される。

【０２０６】子クラスとその親クラスとの間に新しいク
ラスを挿入する時、２つの制約が観察されなければなら
ない。第１に、子クラスのインスタンスが作成される前
に、挿入は完了していなければならない。第２に、挿入
されたクラスは、また、オリジナルの親クラスのすぐ下
の子でなければならない。実行時にクラスの間の関係を
確立する時仲介者としてＳＯＭクラス・マネージャが使
われるので、静的に連係されたクラスは、この様に、陰
になることができる。

【０２０７】図１１は、本発明に従って静的に定義され
たクラス階層の陰の親クラスを作成する詳細を示すフロ
ーチャートである。制御はブロック１１００で始まり、
ブロック１１１０で、静的に定義された親クラス・オブ
ジェクトが作成される。次に、ブロック１１２０で、影
の親クラスが作成され、静的に定義された親クラスを上
書きするために使われる。次に、ブロック１１３０で、
子クラスが作成され、子クラスは（静的に定義されたも
のでなくむしろ）現在の親クラスを確かめるためＳＯＭ
クラス・マネージャに問い合わせを行う。制御は、ブロ
ック１１４０で戻る。

【０２０８】次に、「メソッド・スタッブ再ディスパッ
チ」について説明する。オブジェクト指向プログラミン
グの中心的要素の１つはメソッド導出である。この処理
は、オブジェクトと、メソッドのＩＤと、メソッド起動
に渡される引数とを与えられるある特定のメソッドを選
択する。Ｃ＋＋の中で使われるものを始めとする多くの
オブジェクト型モデルにおけるメソッド導出は、プログ
ラムのソース・コードの分析に基づくプロシージャ入口
ポイントを含むオブジェクト特有テーブルへのオフセッ
トを決定することからなる。この種の導出は、オブジェ
クト型モデルにおいて静的導出と呼ばれる。Smalltalk
のようなその他のオブジェクト型モデルにおいては、実
行時に特定のメソッドを決定するためにオブジェクト名
を使うことからなる一層動的モデルが、使われる。これ
はオブジェクト型モデルにおいて動的導出と呼ばれる。

【０２０９】本発明は、これら静的と動的モデルの間の
差をなくすため再ディスパッチ・スタッブと呼ばれるプ
ログラミング・メカニズムを含める。再ディスパッチ・
スタッブは、プロシージャ入口ポイント・テーブルに置
かれることができる入口ポイントをもつ小さなプロシー
ジャである。プロシージャ入口ポイントのテーブルが、
予想される実際のメソッド入口ポイントのための置き換
えとして、静的オブジェクト型モデルにおいて、使われ
る。動的モデルにおいては、再ディスパッチ・スタッブ
は、動的オブジェクトの要求を基に、自動的に生成され
る。再ディスパッチ・スタッブは、静的オブジェクト・
モデルで生成される呼び出しを動的オブジェクト・モデ
ルで必要な形態に変換し、プロセスにおいて欠落してい
る情報を供給する。かくして、あるオブジェクトが、動
的オブジェクト・モデルによって提供される静的オブジ
ェクト・モデルからアクセスされる場合、オブジェクト
は、各々特定の再ディスパッチ・スタッブを示す入口ポ
イント・テーブルを通して、静的オブジェクト・モデル
に与えられる。

【０２１０】図１２は、本発明に従う再ディスパッチ・
メソッドを示す流れ図である。ラベル１２００は、特定
のオブジェクトに関する状態データ構造である。最初の
フルワード（ラベル１２１０）は、オブジェクトのメソ
ッド・プロシージャ・テーブル（ラベル１２４０）のア
ドレスを含む。状態データ構成の残り（ラベル１２３
０）は、該オブジェクトに関する付加情報を含む。メソ
ッド・プロシージャ・テーブル（ラベル１２４０）は、
特定のオブジェクトに対する種々のメソッドのアドレス
を含む。このオブジェクトと同じクラスに属するすべて
のオブジェクトは、このメソッド・プロシージャ・テー
ブル（ラベル１２４０）をポイントするアドレスを含
む。オブジェクトによって継承されるいかなるメソッド
も、その継承元の先祖クラスのメソッド・プロシージャ
・テーブル（ラベル１２４０）に含められるものと同じ
メモリ内オフセット値でそれらのメソッド・プロシージ
ャ・アドレスを持つ。

【０２１１】図１２において、ラベル１２５０が、再デ
ィスパッチ・スタッブ１２７０へのポインタを含む。再
ディスパッチ・スタッブは、メソッドとして現れるユー
ザ・プログラムに対する命令シーケンスである。しか
し、その命令は単にメソッド呼び出しを、オブジェクト
の適切なディスパッチ関数への呼び出し(ラベル１２６
０)に変換するだけである。ラベル１２６０におけるア
ドレスは、オブジェクトのディスパッチ関数１２８０へ
のポインタである。すべてのＳＯＭオブジェクトは、デ
ィスパッチ関数を持つ。ディスパッチ関数１２８０は、
再ディスパッチ・スタッブによって渡されたパラメータ
に基づき特定のメソッドを選択するアルゴリズムを実行
する。これらのパラメータには、メソッドの識別名、識
別されたメソッドへ渡される一組の引数を記述した文字
列、および、引数を含むデータ構造とが含まれる。

【０２１２】次に、「オフセット値」について説明す
る。図１３は、単一のパブリック・インスタンス変数に
関し、ＳＯＭクラス・データ構造におけるオフセット値
初期化の詳細を示すフローチャートである。この論理シ
ーケンスは、特定のクラス（上述のＯＩＤＬデータ部参
照）で定義される各パブリック・インスタンス変数に対
し繰り返される。制御は、ブロック１３００で始まり、
直ちにブロック１３１０に進み、このクラスのオブジェ
クト状態データの範囲内のインスタンス変数のオフセッ
ト値を、オブジェクト状態データ構造の範囲内のこのク
ラスのオブジェクト状態データの始めのオフセット値に
加えることによって、インスタンス変数のオフセット値
が計算される。クラスのオブジェクト状態データの始め
は、このクラスの先祖クラスのオブジェクト状態データ
の各々のサイズを合計することによって決定される。次
に、ブロック１３２０で、ＯＩＤＬファイルのリリース
順序部におけるパブリック・インスタンス変数の名の位
置によって決定されるクラス・データ構造上の位置に、
計算されたオフセットは、記憶される。制御は１３３０
に進み、プロセスは完了する。

【０２１３】次に、「再ディスパッチ・スタッブ」につ
て説明する。図１４は、再ディスパッチ・スタッブが静
的メソッド呼び出しを動的メソッド呼び出しに変換する
ために使われる場合の詳細な制御の流れを示すフローチ
ャートである。制御は、ブロック１４００で始まり、直
ちにブロック１４１０に進み、再ディスパッチ・スタッ
ブのアドレスは、クラスが定義された時決定された位置
における該当するクラス・データ構造に含まれるオフセ
ット値で、オブジェクトのメソッド・プロシージャ・テ
ーブルに記憶されるアドレスを受け取ることによる普通
の静的メソッド導出方法で決定される。次に制御はブロ
ック１４２０に進み、再ディスパッチ・スタッブが、ま
さに現実の静的メソッド・プロシージャであるかのよう
に呼び出される。ブロック１４３０で、再ディスパッチ
・スタッブは、（先に述べたように普通のメソッド導出
を使用して）オブジェクトのディスパッチ・メソッドを
呼び出す。再ディスパッチ・スタッブは、オブジェクト
のディスパッチ・メソッドによって必要とされる場合、
メソッドの識別名と記述子を呼び出しに加える。これら
の値は、再ディスパッチ関数定義がＳＯＭ ＯＩＤＬコ
ンパイラによって生成される時再ディスパッチ関数定義
に組み入れられる。SOMObjectクラスの定義についての
上記説明の通り、すべてのクラスがディスパッチ・メソ
ッドをサポートしなければならないという点に注意され
るべきである。オブジェクトのディスパッチ・メソッド
・プロシージャは、どの実際のメソッド・プロシージャ
がオブジェクトのクラスに特有のアルゴリズムを使用し
て呼び出されなければならないかを決める（ブロック１
４４０）。

【０２１４】ＳＯＭは、メソッド・プロシージャのアド
レスを決定するためメソッドの識別名をオブジェクトの
クラス・オブジェクトに含まれるテーブルで照合するよ
うなアルゴリズムを省略時解釈での実現として提供す
る。その他のオブジェクト・モデルは、その他のアルゴ
リズムを使用してもよい。制御はブロック１４５０に進
み、ブロック１４４０で決定されたメソッド・プロシー
ジャが呼び出される。メソッド・プロシージャがその戻
り値を戻す時、再ディスパッチ・スタッブの呼出し元に
その値が戻される（ブロック１４６０）。再ディスパッ
チ・スタッブによって、オブジェクトを処理している適
用業務プログラムでの変更を必要とせずに、オリジナル
の静的メソッド呼び出しを任意の動的呼び出しの１つに
変換することが可能となる。

【０２１５】次に、「メソッド・プロシージャ・テーブ
ルの初期化」の説明を行う。図１５は、該クラスを使用
する適用業務の実行の間メソッドに対するメソッド・プ
ロシージャの関係付けを変更する可能性のあるメソッド
・プロシージャ・テーブルを正しく初期化する制御の流
れの詳細を示すフローチャートである。制御は、ブロッ
ク１５００で始まり、直ちにブロック１５１０に進み、
空き領域がメソッド・プロシージャ・テーブルのために
割り当てられる。クラスのオブジェクトのアドレスのた
めのエントリと、図７に従ってクラスによって継承され
るかあるいは定義されるメソッドの各々とを記憶するた
めの十分な空き領域が割り当てられる。次にブロック１
５２０で、メソッド・プロシージャ・テーブルにおける
各メソッド・エントリが再ディスパッチ・スタッブによ
って置き換えられる。継承のための再ディスパッチ・ス
タッブは、クラスの親クラスからそれらを要請すること
によって決められる。

【０２１６】クラスのための再ディスパッチ・スタッブ
は、ＳＯＭコンパイラによって生成され、クラスの静的
メソッドの各々を登録するための呼び出しにおけるクラ
ス初期化プロシージャに供給される。制御は、ブロック
１５３０に進み、クラスのディスパッチ関数に関するメ
ソッド・プロシージャ・テーブル・エントリは、クラス
のディスパッチ関数の実アドレスによって置き換えられ
る（無限ループになるため、ディスパッチ関数スロット
で再ディスパッチ・スタッブ・アドレスを持つことは絶
対正しくない）。最後に、制御はブロック１５４０へ渡
り、処理は終了する。

【０２１７】次に、「派生メタクラスの準備」に関し説
明を行う。図１６は、図６のステップ６５０で示された
指定された１組の親クラスと派生に含まれるべくプログ
ラマによって指定された明示的または暗示的メタクラス
とが与えられるものとして、新しいクラスのためのメタ
クラスを派生する制御の流れの詳細を示すフローチャー
トである。制御は、ブロック１６００で始まり、ブロッ
ク１６１０で、親クラスおよび明示的または暗示的メタ
クラスがアクセスされ、次に続く制御の流れにおける計
算での使用が可能となる。制御はブロック１６２０へ進
み、親（複数）のメタクラスのリストに、明示的または
暗示的メタクラスを付加することによってメタクラスの
リストが作成される。各親クラスがその親のためにメタ
クラスを戻すメソッド<somGetClass>に応答するので、
このリストは、ＳＯＭで簡単に作成される。このリスト
が作成されると、次に、ブロック１６３０で、メタクラ
スのリストがフィルタにかけられ、明示的または暗示的
メタクラスを含むと保証されるメタクラスでのみ構成さ
れるセット（以下カバー・セットと呼ぶ）が決定され
る。このようなカバー・セットの中のメタクラスはいず
れも、その他のメタクラスの派生でない。言い換える
と、第２のメタクラスへの先祖メタクラスが第２のメタ
クラスが派生される第１のメタクラスにおいて見い出さ
れる場合、すべてのデータおよびメソッドが先祖メタク
ラスにおいて見い出されることができるので、第２のメ
タクラスは取り除かれる。そのようなものがあれば、そ
れはフィルターされた結果から取り除かれる。メタクラ
スのカバー・セットが決定されると、制御はブロック１
６４０に進み、そこで、カバー・セットの中のメタクラ
スの数が調べられる。もしもカバー・セットにただ１つ
のメタクラスが（少くとも１つは常に存在しなければな
らない）存在する場合、制御はブロック１６５０に進
み、新しいクラスのために使われるべきメタクラスとし
てこのメタクラスが戻される。

【０２１８】その代わりに、もしも複数のメタクラスが
あれば、制御はブロック１６６０に進む。ブロック１６
６０の目的は、クラスを決定すること、すなわち、カバ
ー・セットの中のすべてのメタクラスからサブクラス化
することによって派生される新しいメタクラスのメタク
ラスを決定することである。これは,ステップ１６００
から１６５０でのカバー・セット派生に対するものと同
様の問題である。ブロック１６６０は、パラメータとし
てカバー・セットのメタクラスと空(nul)の明示的また
は暗示的メタクラスを使用して最初のブロック１６００
への再帰呼出しを作る。１つのメタクラスが存在する
と、新しいメタクラスのクラスが決定され、ブロック１
６７０で、新しいメタクラスのクラスが新しいメタクラ
スを作成するために使われる。次に、ブロック１６８０
で、メタクラス・オブジェクト上のクラス初期化メソッ
ドを起動し、その親としてのメタクラスのカバー・セッ
トを識別することによって、新しいメタクラスが初期化
される。新しいメタクラスが初期化された後、制御の流
れはブロック１６９０に渡り、そこで、新しいクラスの
ために使われるメタクラスとして新しいメタクラスが戻
される。上記において、カバー・セットが作成された
後、必要に応じてメタクラスをリストに追加することも
可能である。

【０２１９】メタクラス派生プロセスの結果を視覚的に
例証するため、図１７はクラス定義の結果を示す。この
例では明示的メタクラスは含まれない。この図におい
て、実線は継承関係を表わすために使われ、サブクラス
をその親クラスの各々と連結する。また、破線は、オブ
ジェクトをインスタンスであるクラスと連結するインス
タンス関係を表わすために使われる。理解を助けるた
め、そのインスタンスに関し各クラス・オブジェクトに
よって定義されるメソッドの例が、クラス名を囲む円の
右側に置かれている。クラスでないオブジェクトは、正
方形を使用して示される。

【０２２０】図１７に関するクラス定義 class: X; parent: SOMObject; method: X* ConstructX(), class; class: Y; parent: SOMObject; method: Y* ConstructY(), class; class: Z; parent: X; parent: Y; 単純化のため、上述のクラス定義は、クラス<X>、<Y>ま
たは<Z>のインスタンスのデータまたはメソッドを示し
ていない。その代わりに、それらはクラス・オブジェク
ト自身がサポートしなければならないメソッドを示す。
例えば、クラス・オブジェクト<X>は、その目的が新し
い<X>インスタンスを構築し初期化することであるメソ
ッド<ConstructX>をサポートする。 構築メソッド<Cons
tructY>をサポートするクラス<Y>に関しても同様であ
る。今や、クラス・メソッドが、メタクラスによって定
義され、従って、例えば、クラス<X>について、<Constr
uctX>を定義する<M_X>と名づけられた暗示的メタクラス
が存在し、クラス<Y>について、<ConstructY>を定義す
る<M_Y>と名づけられた暗示的メタクラスが存在する。
クラス<Z>は、暗示的メタクラスも明示的メタクラスも
持たず、何がそのメタクラスあるかを決定することが必
要である。さもなければ、あらゆるオブジェクトはある
特定クラスのインスタンスでなければならないので、<Z
>クラス・オブジェクトは、作成できない。従って、図
１７で示されるように<M_X>と<M_Y>とからクラス・メソ
ッドを継承するため、新しいメタクラスが、図１６で詳
述されたアプローチを使用して派生され、<M_X>と<M_Y>
とからクラス・メソッドを継承する。<DM_Z>と名付けら
れたこの派生メタクラスは、クラス<Z>に関して構築メ
ソッド<ConstructX>と構築メソッド<ConstructY>とを定
義する。この結果、そのクラス<X>にアクセスし、次
に、<ConstructX>メソッドを起動する<X>のインスタン
スに適切ないかなるコードも、また、<Z>のインスタン
スがクラス<Z>をアクセスし、<ConstructX>を起動する
ことに適している。同様に、<Y>のインスタンスに適切
なコードは、クラス<Z>をアクセスし、<ConstructX>を
起動する<Z>のインスタンスに適している。<X>または<Y
>インスタンスのため動作するコードは、また、<Z>イン
スタンスのため動作する。これは、この例のように親<X
>および<Y>から<Z>が派生される場合、オブジェクト指
向システムが行わなければならない保証である。

【０２２１】メタクラス派生プロセスの結果をさらに例
証するため、図１８はクラス定義の別の結果を示す。こ
れは図１７と同じであるが、この例では明示的メタクラ
スが含まれる。図１８の重要な面は、<Z>のメタクラス
は<M_Z>でないという点である。メタクラスはプログラ
マによって明示的に識別されるが、むしろ、それは<DM_
Z>であり、<M_X>と<M_Z>を含むカバー・セットから自動
的に派生される。

【０２２２】図１８のクラス定義 class: X; parent: SOMObject; method: X* ConstructX(), class; class: Y; parent: SOMObject; method: Y* ConstructY(), class; class: M_Z; parent: M_Y; method: Z* ConstructZ(); class: Z; metaclass（メタタクラス）: M_Z; parent: X; parent: Y; 本明細書において本発明が上記特定の実施例に関して記
述されたとはいえ、本発明の意図と対象範囲からはずれ
ることなく上記実施例に対し修正を行うことができる点
は当業者によって理解されることであろう。

【０２２３】

【発明の効果】本発明に従うＳＯＭにおけるメタクラス
派生技術の適用によって、複数の親クラスをサブクラス
化することによって新しいクラスを派生する場合でも、
該メタクラスは、親クラスからのサブクラス化によって
開発されるクラス・インスタンスを完全にサポートする
ことが可能となる。

【０２２４】また、あるクラスのためのメソッド各々に
関しユニークな外部名を必要とする過去のオブジェクト
指向テクニックを改善するため、本発明に従うＳＯＭは
各クラス実現と関連する特別なプロシージャを用いて、
実行時にクラス・メソッド・テーブルを初期化し、メソ
ッド・オフセット値をすべて外部的名前をもつ単一のク
ラス・データ構造に集めるが、この改善によって、外部
変数の大きいリストを管理するという複雑さが減少し、
ユニークな名を創造するという問題を解決し、メモリ要
求を減らし、生成された実行モジュールのロード時間を
減らすという効果をもたらす。

【０２２５】さらにまた、本発明に従うオブジェクト指
向プログラミングにおける陰の親クラスと呼ばれる、置
き換え親クラスの動的挿入を行う技術によって、コード
がバイナリ形式となった後、既存のコードを維持し、改
良するための柔軟性が大幅に増加し、ソース・コード等
にアクセスせずにコードをカスタマイズできる新しい自
由度が増す。

【０２２６】かくして、本発明は、オブジェクト指向プ
ログラミングにおける従来技術における問題点を解決
し、オブジェクト指向プログラム開発生産性向上とプロ
グラム実行パフォーマンスの改善を実現する。

【図面の簡単な説明】

【図１】本発明に従うパーソナル・コンピュータ・シス
テムのブロック図である。

【図２】本発明に従うＳＯＭデータ構造を示す。

【図３】本発明に従うＳＯＭクラス・データ構造を示
す。

【図４】本発明に従う言語中立的オブジェクト・インタ
ーフェースを記述するフローチャートである。

【図５】本発明に従うＳＯＭオブジェクトを使用する適
用業務の連係、ロードおよび実行を説明するフローチャ
ートである。

【図６】本発明に従う新しいＳＯＭクラスの作成を記述
するフローチャートである。

【図７】本発明に従う新しいＳＯＭクラス構築の詳細を
示すフローチャートである。

【図８】本発明に従う新しいＳＯＭの一般的クラス・オ
ブジェクト構築の詳細を示すフローチャートである。

【図９】本発明に従う新しいＳＯＭクラス・オブジェク
トの初期化の詳細を記したフローチャートである。

【図１０】本発明に従うオフセット値をもつＳＯＭクラ
ス・データ構造の初期化の詳細を示すフローチャートで
ある。

【図１１】本発明に従って静的に定義されるクラス階層
の陰の親クラス作成の詳細を示すフローチャートであ
る。

【図１２】本発明に従う再ディスパッチの方法を示す流
れ図である。

【図１３】本発明に従って、単一のパブリックのインス
タンス変数に関するＳＯＭクラス・データ構造における
オフセット値初期化を示すフローチャートである。

【図１４】本発明に従って、静的メソッド呼び出しを動
的メソッド呼び出しに変換するために再ディスパッチ・
スタッブが使われる場合の制御の流れを示すフローチャ
ートである。

【図１５】本発明に従ってあるクラスのためのメソッド
手続きテーブルを初期化する詳細な制御の流れを示すフ
ローチャートである。

【図１６】本発明に従って、プログラマによって定義さ
れる新しいクラスを実現するために使われるメタクラス
を派生する詳細な制御の流れを示すフローチャートであ
る。

【図１７】図１６のフローチャートによって例示された
アルゴリズムの動作を例証するため、単純なメタクラス
派生の結果を記述する図である。

【図１８】図１６のフローチャートによって例示された
アルゴリズムの動作を例証するため、一層複雑なメタク
ラス派生の結果を記述する図である。

【符号の説明】

１０ ＣＰＵ １４ ＲＡＭ １６ ＲＯＭ １８ 入出力アダプタ ２０ ディスク装置 ２２ ユーザ・インターフェース・アダプタ ２４ キーボード ２６ マウス ３６ ディスプレイ・アダプタ ３８ 表示装置 ２２０ メソッド・プロシージャ・テーブルのアドレス ２４０ メソッド・プロシージャ・テーブル ２４５ クラス・オブジェクト・データ構造のアドレス ２４８ クラス・オブジェクト・データ構造 ３１０ クラス・オブジェクト・データ構造 ３２０ メソッド・プロシージャ・テーブルまたはオブ
ジェクト状態データ構造へのオフセット値 １２００ オブジェクト状態データ構造 １２２０ メソッド・プロシージャ・テーブルのアドレ
ス １２４０ メソッド・プロシージャ・テーブル １２５０ 再ディスパッチ・スタッブへのポインタ １２６０ ディスパッチ関数へのポインタ １２７０ 再ディスパッチ・スタッブ １２８０ ディスパッチ関数

Claims (14)

【特許請求の範囲】
1. 【請求項１】少なくとも１つの親クラスのサブクラス化
   によって新しいクラスのためのメタクラスを派生する方
   法であって、 上記新しいクラスをメモリ上に構築するため一組の命令
   を実行するステップと、 少くとも1つの親クラスに関する親クラスのメタクラス
   と第２のメタクラスとに基づいて、新しいクラスのため
   の新しいクラス・メタクラスを派生するステップと、 上記新しいクラス・メタクラスに従ってメモリ上に上記
   新しいクラスを作成するステップと、 を含むクラス派生の方法。
2. 【請求項２】上記新しいクラス・メタクラスが、複数の
   親クラス・メタクラスから派生されるものであり、上記
   第２のメタクラスが、上記新しいクラスがサブクラス化
   される第２の親クラスに関する第２の親クラス・メタク
   ラスである請求項１記載の方法。
3. 【請求項３】上記第２のメタクラスが、上記新しいクラ
   スのため定義されるメタクラスである請求項１記載の方
   法。
4. 【請求項４】上記定義されるメタクラスが、暗示的メタ
   クラスである請求項３記載の方法。
5. 【請求項５】上記定義されるメタクラスが、明示的メタ
   クラスである請求項３記載の方法。
6. 【請求項６】上記派生する方法が、 複数の親クラスを基に親クラス・メタクラスのリストを
   作成するステップと、 上記親クラス・メタクラスのリストをフィルターにか
   け、カバー・メタクラスのリストを作成するステップ
   と、 カバー・メタクラスのリストをサブクラス化することに
   よって、新しいクラス・メタクラスを派生するステップ
   と、 を含む請求項２記載の方法。
7. 【請求項７】上記親のクラス・メタクラスのリストにさ
   らに付加的メタクラスを追加するステップを含む請求項
   ６記載の方法。
8. 【請求項８】少なくとも１つの親クラスのサブクラス化
   によって新しいクラスのためのメタクラスを派生するた
   めのシステム装置であって、 上記新しいクラスをメモリ上に構築するため一組の命令
   を実行する手段と、 少くとも1つの親クラスに関する親クラスのメタクラス
   と第２のメタクラスとに基づいて、新しいクラスのため
   の新しいクラス・メタクラスを派生する手段と、 上記新しいクラス・メタクラスに従ってメモリ上に上記
   新しいクラスを作成する手段と、 を含むクラス派生のためのシステム装置。
9. 【請求項９】上記新しいクラス・メタクラスが、複数の
   親クラス・メタクラスから派生されるものであり、上記
   第２のメタクラスが、上記新しいクラスがサブクラス化
   される第２の親クラスに関する第２の親クラス・メタク
   ラスである請求項８記載のシステム装置。
10. 【請求項１０】上記第２のメタクラスが、上記新しいク
    ラスのため定義されるメタクラスである請求項８記載の
    システム装置。
11. 【請求項１１】上記定義されるメタクラスが、暗示的メ
    タクラスである請求項１０記載のシステム装置。
12. 【請求項１２】上記定義されるメタクラスが、明示的メ
    タクラスである請求項１０記載のシステム装置。
13. 【請求項１３】上記メタクラス派生のためのシステム装
    置が、 複数の親クラスを基に親クラス・メタクラスのリストを
    作成する手段と、 上記親クラス・メタクラスのリストをフィルターにか
    け、カバー・メタクラスのリストを作成する手段と、 カバー・メタクラスのリストをサブクラス化することに
    よって、新しいクラス・メタクラスを派生する手段と、 を含む請求項９記載のシステム装置。
14. 【請求項１４】上記親のクラス・メタクラスのリストに
    さらに付加的メタクラスを追加する手段を含む請求項１
    ３記載のシステム装置。