JPH05274151A - クラスをシャドウ化するシステム及び方法 - Google Patents

Abstract

(57)【要約】 【目的】 本発明の目的は、誘導クラスとその親クラス
の間の束縛をサポートする動的な機構を導入することで
ある。 【構成】 本発明によれば、クラス・オブジェクトの登
録、および登録機構に基づいて親クラス・オブジェクト
に対する誘導クラス・オブジェクトの動的束縛を提供す
る、プロセッサのメモリ内のアルゴリズムの動作が提供
される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、全般的には、オブジェ
クト指向アプリケーションの改良に関し、具体的には、
用いられるクラスの実装が静的階層を前提に作成された
時であっても、クラス階層を走行中に変更できるように
することに関する。

【０００２】

【従来の技術】ワークステーション・ソフトウェアの開
発者の間では、オブジェクト指向プログラミング（また
はＯＯＰ）が、重要な新しいプログラミング技術として
次第に認識されつつある。これは、ソフトウェア再利用
の可能性を拡大し、拡張性を提供し、従来のソフトウェ
ア開発パラダイムに比べてプログラマの生産性を向上さ
せる。にもかかわらず、オブジェクト指向技術は、今日
まで主要な市販ソフトウェア製品に実際に浸透してこな
かった。具体的に言うと、オペレーティング・システム
にこの新技術を含めることに対して抵抗があった。

【０００３】新しいプログラミング技術の多くと同様
に、ＯＯＰ概念の初期の表現は、それぞれ特定の態様を
利用するように設計された、新しい言語およびツールキ
ットの作成を中心としていた。Ｓｍａｌｌｔａｌｋな
ど、いわゆる純粋なオブジェクト指向言語は、その意味
論が従来の手続き指向システム・アーキテクチャから大
きく離れたものであったことから、完全な実行時環境
（仮想計算機と称することもある）を前提とするもので
ある。一方、Ｃ＋＋などのハイブリッド言語において
は、必要な実行時サポートはより少ないが、オブジェク
トを提供するプログラムとそのオブジェクトを使用する
クライアント・プログラムの間で密な束縛をもたらすこ
とがある。オブジェクトを提供するプログラムとそのク
ライアントとの間の束縛が密であると、提供側プログラ
ムに簡単な変更を加える際に、しばしば、クライアント
・プログラムの再コンパイルが必要となる。このような
システムの例は、米国特許第４８８５７１７号、第４９
５３０８０号および第４９８９１３２号明細書に見られ
る。

【０００４】異なる言語およびオブジェクト指向ツール
キットは、ＯＯＰの異なる態様を強調するので、それか
ら得られるソフトウェアの有用性は、しばしば範囲が制
限される。たとえば、Ｃ＋＋プログラマは、Ｓｍａｌｌ
ｔａｌｋで開発されたオブジェクトを簡単には使用でき
ないし、Ｓｍａｌｌｔａｌｋプログラマは、Ｃ＋＋のオ
ブジェクトを有効に利用できない。ある言語で簡単に実
装されたオブジェクトおよびクラスが、別の言語ですぐ
には使用できない。不幸なことに、このような状況が発
生する時には、ＯＯＰの主な利点の１つであるコードの
再利用性の増加が、大きく制約される。オブジェクト指
向の言語およびツールキットの境界が、実際には、相互
操作性に対する障壁となる。

【０００５】オブジェクト指向プログラミングでは、プ
ログラムを、クラスと称するオブジェクト定義に編成す
る。これらのクラスのほとんどは、誘導クラス（derive
d class:派生クラスとも呼ばれる）である。すなわち、
その仕様および実装の一部を、親クラスと称する別のク
ラスから得ている。親クラスから仕様および実装を誘導
する（derive）には、誘導クラスは、その実装に際して
親クラスを参照しなければならない。さらに、メソッド
・テーブルなどのサポート用クラス・データ構造を、誘
導クラスと親クラスの両方の実装から作成しなければな
らない。従来の技術では、これが、誘導クラスの２進イ
メージ(birary image)と親クラスの２進イメージの間の
静的参照をもたらしていた。これらの静的参照は、誘導
クラスを使用するアプリケーションが、その実行中にそ
の誘導クラスが参照する親クラスを、別の親クラスで置
き換えられないことを意味していた。これが、柔軟性の
なさをもたらし、誘導クラスの再利用性を制限してきた
のである。

【０００６】

【発明が解決しようとする課題】本発明の主目的は、誘
導クラスとその親クラスの間の束縛をサポートする動的
な機構を導入することである。

【０００７】

【課題を解決するための手段】本発明の上記その他の目
的は、クラス・オブジェクトの登録、およびこの登録機
構に基づく親クラス・オブジェクトへの誘導クラス・オ
ブジェクトの動的束縛を提供する、プロセッサのメモリ
内のアルゴリズムの動作によって達成される。システム
・オブジェクト・モデル（ＳＯＭ）は、すべての親クラ
ス情報を親クラス・オブジェクトを介して実行時に使用
可能にすることによって、クラス・オブジェクトに対す
る静的参照を取り除く。したがって、誘導クラスの実装
が、親クラス状態データ構造のサイズ、親クラス・メソ
ッド手続きのアドレス、または、親クラス・メソッド手
続きテーブルへのアクセスに関する情報を必要とする
時、親クラス・オブジェクトから適切な情報が検索され
る。

【０００８】誘導クラスは、その親クラス・オブジェク
トへの接続（結合）を確立しなければならない。これを
サポートするために、ＳＯＭは、各ＳＯＭプロセス用に
クラス・マネジャを導入する。クラス・マネジャは、ク
ラスの登録簿を保持する責任を負う。ＳＯＭコンパイラ
によって生成されるクラス構築コードが、クラス・マネ
ジャと共に働いて、子クラス・オブジェクトが作成され
る際に、子クラスとその親クラスの間の関係を確立す
る。ＳＯＭクラス・マネジャは、他のＳＯＭクラスと同
様にサブクラスに分けることのできるクラスのインスタ
ンスである。また、ＳＯＭクラス・マネジャは、そのサ
ブクラスのうちの１つのインスタンスが、その省略時ク
ラス管理を完全に包含できるようにするメソッドを含
む、特別な手段を有する。したがって、あるクラスを
「親にしなおす」能力を必要とするコンパイル済みソフ
トウェア環境は、ＳＯＭクラス・マネジャをサブクラス
に分け、これを新しいクラス・マネジャ・インスタンス
で置き換えた後、クラスを見つけ出してこれらクラス間
の関係を解決する新しい規則を施行することによって、
所定のクラスを親クラスとすることができる。

【０００９】

【実施例】本発明は、ＩＢＭ社から市販されているＩＢ
Ｍ ＰＳ／２コンピュータ上に常駐するオペレーティン
グ・システムの環境で実装することが好ましい。代表的
なハードウェア環境を、図１に示す。図１は、従来式の
マイクロプロセッサなどの中央演算処理装置１０と、シ
ステム・バス１２を介して相互接続された複数の他の装
置とを有する、本発明によるワークステーションの典型
的なハードウェア構成を示す図である。図１に示したワ
ークステーションは、ランダム・アクセス・メモリ（Ｒ
ＡＭ）１４と、読取専用メモリ（ＲＯＭ）１６と、ディ
スク装置２０などの周辺装置をバスに接続するための入
出力アダプタ１８と、キーボード２４、マウス２６、ス
ピーカ２８、マイクロフォン３２、タッチ・スクリーン
（図示せず）などのユーザ・インターフェース装置をバ
スに接続するためのユーザ・インターフェース・アダプ
タ２２と、ワークステーションをデータ処理ネットワー
クに接続するための通信アダプタ３４と、バスを表示装
置３８に接続するための表示装置アダプタ３６とを含ん
でいる。このワークステーション上には、ＯＳ／２に基
づくオペレーティング・システムと、本発明を構成し、
ツールキットとして含まれるコンピュータ・ソフトウェ
アが常駐する。

【００１０】本実施例は以下のように構成される。 Ａ．オブジェクト指向プログラミングの紹介 （ｉ）Ｃ言語でのオブジェクト指向プログラミング （ii）Ｃ⁺⁺との比較 Ｂ．ＳＯＭの紹介 Ｃ．ＳＯＭでのクラス定義 Ｄ．メソッドの記述のしかた Ｅ．ＳＯＭを使用する機構 Ｆ．他のクラスからＳＯＭクラスを作成する方法 （ｉ）誘導 （ii）構築 Ｇ．ＳＯＭクライアント Ｈ．ＳＯＭのオブジェクト・モデル Ｉ．ＳＯＭの基本クラス （ｉ）ＳＯＭ Ｏｂｊｅｃｔ （ａ）動的オブジェクト・モデルをサポートするＳＯＭ
Ｏｂｊｅｃｔメソッド （ｂ）開発を支援するＳＯＭ Ｏｂｊｅｃｔメソッド （ii）ＳＯＭ Ｃｌａｓｓ （iii）ＳＯＭ Ｃｌａｓｓ Ｍｇｒ Ｊ．オブジェクト名の管理 Ｋ．オブジェクト・インターフェース定義言語（ＯＩＤ
Ｌ） Ｌ．ＳＯＭコンパイラ Ｍ．オブジェクト指向のプログラムのバージョン独立性 Ｎ．アプリケーションの２進イメージからのオブジェク
ト状態データ構造サイズの除去 Ｏ．親クラスのシャドウ化 Ｐ．再ディスパッチ・メソッド・スタブ （ｉ）オフセット値 （ii）再ディスパッチ・スタブ （iii）メソッド手続きテーブルの初期設定

【００１１】 Ａ．オブジェクト指向プログラミングの紹介 オブジェクト指向プログラミングは、高品質で再利用可
能なコードを開発する上で重要な方法として、急速に地
位を固めつつある。本発明は、クラス・ライブラリおよ
びオブジェクト指向プログラムを開発するための新型シ
ステムを含む。このシステムを、システム・オブジェク
ト・モデル（ＳＯＭ）と称する。本発明の理解を助ける
ため、オブジェクト指向プログラミング、ＳＯＭおよび
他のオブジェクト指向言語との比較につて詳細に説明す
る。

【００１２】ソフトウェア業界で新たに開発されたの
が、オブジェクト指向プログラミングである。オブジェ
クト指向プログラミング言語（ＯＯＰＬ）は、この業界
全体で使用されつつあり、オブジェクト指向データベー
ス（ＯＯＤＢ）は、広範囲の関心を集め始めており、オ
ブジェクト指向設計分析（ＯＯＤＡ）ツールさえも、シ
ステムの設計とモデル化の方法を変えようとしている。

【００１３】オブジェクト指向プログラミングは、非常
に近い関係にある構造化プログラミングと対比すると最
もよく理解できる。これらはどちらも、ますます複雑に
なるソフトウェア・システムの複雑さを管理するという
同じ基本的な問題を扱おうとするものである。構造化プ
ログラミングでは、システムを層化された１組の機能モ
ジュールとしてモデル化する。これらのモジュールは、
各層がそれぞれシステムの別の層より高い水準から見た
姿を表す、ピラミッド風の形に組み立てられる。構造化
プログラミングでは、システムの挙動（behavior)はモ
デル化するが、システムの情報をモデル化するための指
針はほとんど与えられない。

【００１４】オブジェクト指向プログラミングでは、シ
ステムを、協働する１組のオブジェクトとしてモデル化
する。オブジェクト指向プログラミングも、構造化プロ
グラミングと同様に、システムの複雑な挙動を管理しよ
うとするものである。しかし、オブジェクト指向プログ
ラミングは、システムの複雑な情報も管理しようとする
点で構造化プログラミングに勝っている。

【００１５】オブジェクト指向プログラミングでは、シ
ステムの複雑な挙動と情報を両方ともモデル化するの
で、そのシステムは、単によく「構造化」されている場
合よりはるかに編成がうまくいく傾向がある。オブジェ
クト指向システムは、うまく編成されているので、理
解、デバッグ、保守および展開が簡単である。うまく編
成されたシステムは、コードの再利用にも適している。

【００１６】オブジェクト指向プログラミングでは、複
雑な情報の管理と複雑な挙動の管理という二重の問題
を、密接に関連するものとして想定する。編成の基本単
位は、オブジェクトである。オブジェクトは、オブジェ
クトの状態(state)と称するいくつかの関連データと、
オブジェクトのメソッド(method)と称する１組の動作と
を有する。メソッドは、サブルーチンによって実装され
る。クラスとは、あるオブジェクトの一般的な記述であ
り、あるオブジェクトの状態を表すデータと、そのオブ
ジェクトをサポートするメソッドを定義する。

【００１７】 （i）Ｃ言語でのオブジェクト指向プログラミング ＳＯＭを吟味する前に、Ｃ言語でのオブジェクト指向プ
ログラミングを検討する。これによって、自然にＳＯＭ
の考え方に導かれる。総称スタック(generic stack)に
関する情報を含むデータ構造定義を検討する。このデー
タ構造は、スタック構造に作用するように設計された一
連の関数を含んでいる。基本的なスタック定義が与えら
れると、ユーザ・プログラム内で、このデータの複数の
インスタンスを宣言することができる。

【００１８】Ｃでの総称スタック定義を以下に示す。 struct stackType { void *stackArray[STACK_SIZE]; int stackTop; }; typedef struct stackType Stack; 総称スタック関数の定義を次に示す。 Stack *create(); /* 新規スタックにメモリを割り振り、 初期設定する */ void *pop( /* スタックから要素をポップする */ Stack *thisStack); void push( /* スタック上にプッシュする */ Stack *thisStack, void *nextElement); ほとんどのＣプログラマは、このような関数がどのよう
に記述されるかを想像できる。たとえば、関数push()
は、以下のようになる。 クライアント・プログラムは、このスタックを使用し
て、たとえば、解釈を必要とする語のスタックを作成す
ることができよう。

【００１９】この例を使って、オブジェクト指向プログ
ラミングを再検討することができる。クラスとは、ある
オブジェクトの定義である。この定義には、そのオブジ
ェクトのデータ要素と、それがサポートするメソッドが
含まれる。Stack（スタック）は、クラスの例である。S
tackは、２つのデータ要素（stackArrayとstackTop）を
含み、３つのメソッド、create()、push()およびpop()
をサポートする。メソッドは、関数に類似しているが、
特定のクラスのオブジェクトに作用するように設計され
ている。オブジェクトは、クラスの特定のインスタンス
（クラスを実体化したもの）である。オブジェクトword
Stackは、クラスStackのオブジェクトである。言い換え
ると、wordStackは、Stackのインスタンスである。

【００２０】どのメソッドにも、それが作用する対象と
なる特定のオブジェクトが必要である。このオブジェク
トを、ターゲット・オブジェクト（時には受取側オブジ
ェクト）と称する。各メソッド（create()を除く）は、
第１パラメータとしてターゲット・オブジェクトを指す
ポインタをとることに留意されたい。これは、１つのプ
ログラムが所与のクラスのオブジェクトを複数有する可
能性があり、そのオブジェクトのそれぞれがあるクラス
・メソッドのターゲットになる可能性があるからであ
る。

【００２１】このタイプの編成には、３つの重要な長所
がある。まず、類似の概念が適している他の状況で再利
用できる、総称的概念が生成される。第２に、自己完結
型のコードが生成され、それをユーザ・プログラムに折
り込む前に、完全に試験することができる。第３に、内
部の詳細が隠ぺいされクライアントが内部に関与しな
い、カプセル化されたコードが開発される。クライアン
ト・プログラムmain()は、Stackクラスに関して、その
名前と、それがサポートするメソッドと、これらのメソ
ッドへのインターフェースの他には何も知る必要がな
い。

【００２２】（ii）Ｃ＋＋との比較 もう１つの有益な比較が、ＳＯＭと、最も広範囲に使用
されているオブジェクト指向プログラミング言語である
Ｃ＋＋との比較である。ＳＯＭは、Ｃ＋＋と類似する点
が多い。どちらも、クラス定義、継承およびオーバーラ
イドされたメソッド（Ｃ＋＋では仮想メソッドと称す
る）をサポートする。またどちらも、カプセル化の概念
をサポートする。しかし、Ｃ＋＋が、独立型のプログラ
ミング努力をサポートするように設計されているのに対
して、ＳＯＭは、商用品質のクラス・ライブラリをサポ
ートすることに焦点を置いている。ＳＯＭとＣ＋＋の相
違の大部分が、この問題に基づいている。Ｃ＋＋のクラ
ス・ライブラリは、バージョンに依存するが、ＳＯＭの
クラス・ライブラリは、バージョンから独立している。
新しいＣ＋＋クラス・ライブラリが発表される時、その
変更が公衆インターフェースに関係しない場合でも、ク
ライアント・コードを全面的に再コンパイルしなければ
ならない。

【００２３】Ｃ＋＋は、Ｃ＋＋という１つの言語でのプ
ログラミングだけをサポートする。ＳＯＭは、複数の言
語をサポートするように設計されている。ＳＯＭは、１
つの言語ではなく、クラス・ライブラリを定義し操作し
リリースするためのシステムである。ＳＯＭは、クラス
およびメソッドの定義に使用されるが、メソッドを実装
する言語の選択は実装者に委ねられており、新しい言語
の構文を学習する必要はない。

【００２４】Ｃ＋＋は、実装態様の隠ぺいまたはカプセ
ル化に関して、最小限のサポートしか提供しない。Ｃ＋
＋のクラス定義は、クライアントにリリースしなければ
ならないが、通常は、私用データおよび私用メソッドの
宣言("private")を含んでいる。ＳＯＭでは、クライア
ントがこれらの実装態様の細部に焦点を置く必要は絶対
にない。クライアントは、公用(public)情報だけを含
む.scファイル群を見るだけでよい。また、Ｃ＋＋は、
限られたメソッド解決機能しか提供しない。ＳＯＭは、
オフセット・メソッド解決策(offset method resolutio
n)、名前ルックアップ解決策(name lookup resolutio
n)、ディスパッチ解決策(dispatch resolution)など、
複数の代替案を提供する。

【００２５】ＳＯＭとＣ＋＋の間のもう１つの興味深い
相違点は、クラスの概念にある。Ｃ＋＋では、クラスの
宣言は構造の宣言に非常に類似している。これは、実行
時に意味を持つ特性を有しないコンパイル時のパッケー
ジである。ＳＯＭでは、あるオブジェクトのクラスが、
１つのオブジェクトになっている。このクラス・オブジ
ェクトは、それ自体が、メタクラスと称するもう１つの
クラスを実体化したものである。クラス・オブジェクト
は、somGetName()、somGetParent()、somFindMethod()
など、Ｃ＋＋には直接対応するものがない有用なメソッ
ドのホストをサポートする。

【００２６】Ｂ．ＳＯＭの紹介 ＯＳ／２ ２．０は、ＳＯＭ（システム・オブジェクト
・モデル）と称する言語中立(languae-neutral)のオブ
ジェクト指向プログラミング機構を含んでいる。上述の
スタックの例のように、従来の言語でオブジェクト指向
プログラムを記述することが可能ではあるが、ＳＯＭ
は、特に、新しいパラダイムをサポートし、手続き型
（または非オブジェクト指向）言語とオブジェクト指向
言語のどちらとも一緒に使用されるように設計されてい
る。

【００２７】オブジェクト指向プログラミングの重要な
要件が、コードの再利用性である。通常、コードの再利
用性は、クラス・ライブラリを使って達成される。今日
のライブラリ技術は、クラス・ライブラリが必ず各言語
に特有であるという点で制限されている。Ｃ＋＋ライブ
ラリをＳｍａｌｌｔａｌｋプログラマが使用することは
できないし、ＳｍａｌｌｔａｌｋライブラリをＣ＋＋プ
ログラマが使用することもできない。明らかに、手続き
型であれオブジェクト指向であれ、どんなプログラミン
グ言語からも使用できるクラス・ライブラリを作成する
のに使用できる、言語中立のオブジェクト・モデルを作
成する必要がある。

【００２８】ＳＯＭは、ほとんどの手続き型言語に欠け
ている３つの重要な機能を導入する。それは、カプセル
化、継承および多形性（polymorphism:本明細書では
「オーバーライド解決策(override resolution)」と称
する）である。継承とは、あるクラス（サブクラスと称
する）の形状と挙動を、別のクラス（親クラスまたはス
ーパークラスと称する）からの増分差として指定する技
法を指す。

【００２９】カプセル化とは、クライアントから実装態
様の細部を隠すことを指す。これは、クライアントが、
システムに悪影響を及ぼす可能性のある変更を実装態様
に加えないようにするものである。たとえば、スタック
の例では、Ｃコードに対して何の保護も与えられていな
かった。クライアントがスタックの内部データ構造を知
る必要がなかったにもかかわらず、クライアントがその
ような実装態様の細部を見られないようにする手だては
なかった。クライアントが、スタック・データの内部要
素を使用し、おそらくは破壊するコードを記述しないよ
うにし向けることはできたが、それを予防することはで
きなかった。

【００３０】継承またはクラス誘導（派生）は、既存の
クラスから新規クラスを生成するための特定の技法であ
る。この能力によって、既存のクラスのより特殊な版で
ある新規クラスを作成できるようになる。たとえば、St
ackクラスに類似しているが、それに加えて先頭の値を
見るためのpeek()や、スタックの完全なリストをプリン
トするためのdump()など、デバッグ用のメソッドもサポ
ートする、DebuggableStackを作成することができる。

【００３１】継承は、コード統合も提供する。したがっ
て、たとえば、GraduateStudent（大学院生）とUnderGr
aduateStudent（学部学生）を定義するクラスを、第３
のクラスStudent（学生）に統合することができる。そ
の後、共通の親であるStudentから誘導されるより特殊
なクラスとして、GraduateStudentとUnderGraduateを定
義するのである。

【００３２】継承は、いくつかの追加の意味論を導入す
る。特殊なクラスは、より一般的なクラスから誘導され
るといわれる。この一般的なクラスを、親クラスと称
し、時には基本クラスと称する。特殊なクラスを、子ク
ラスと称し、時には誘導クラスと称する。子クラスは、
その親クラスの特性を継承すると言われ、これは、親ク
ラス用に定義されたどのメソッドも、子クラス用に自動
的に定義されることを意味する。したがって、Graduate
StudentとUnderGraduateStudentは、どちらもStudentか
ら誘導されるので、どちらも、共通の親で宣言されたど
のメソッドをも自動的に獲得する。

【００３３】オーバーライド解決策とは、呼び出された
メソッドが、そのメソッドの名前だけに基づくのではな
く、クラス階層内でのそのクラスの位置にも基づいて解
決されることを指す。これによって、クラスを誘導する
際にメソッドが再定義できるようになる。Student用のp
rintStudentInfo()メソッドを定義した後に、UnderGrad
uateStudentとGraduateStudentの両方で、このメソッド
をオーバーライドまたは再定義することができる。オー
バーライド解決策は、ターゲット・オブジェクトのタイ
プに基づいて解決される。ターゲット・オブジェクトの
タイプがStudentである場合には、Student版のprintStu
dentInfo()が呼び出される。ターゲット・オブジェクト
のタイプがGraduateStudentである場合には、GraduateS
tudent版のprintStudentInfo()が呼び出される。

【００３４】Ｃ．ＳＯＭでのクラス定義 ＳＯＭでクラス・ライブラリを作成する処理は、３段階
の処理である。クラス設計者は、クラス・インターフェ
ースを定義し、クラス・メソッドを実装し、最後に、そ
の結果得られるオブジェクト・コードをクラス・ライブ
ラリにロードする。クライアントは、これらのクラスを
直接に使用するか、そのクライアントに特有の目的に合
わせて変更を行うか、あるいはクライアント自体の完全
に新規のクラスを追加する。

【００３５】ＳＯＭでは、クラスは、クラス定義ファイ
ルを作成することによって定義される。クラス定義ファ
イルには、"csc"という拡張子を含む名前をつける。最
も基本的な書式では、クラス定義ファイルは、下記の各
部分に分割される。

【００３６】１．include（組込み部分） この部分では、組み込む必要のあるファイルを宣言す
る。この部分は、Ｃの#include指令にかなり類似してい
る。

【００３７】２．class（クラス名とオプション） この部分では、クラスの名前を定義し、様々なオプショ
ンを宣言する。

【００３８】３．parent（親情報） この部分では、このクラスの親クラスまたは基本クラス
を定義する。クラスは、必ず親を有することが必要であ
る。あるクラスが既存のクラスから誘導されるのではな
い場合には、その親は、ＳＯＭで定義されるクラスSOMO
bjectになる。SOMObjectのクラス情報は、ファイルsomo
bj.scにある。

【００３９】４．data（データ部分） この部分では、このクラスのオブジェクトに含まれるす
べてのデータ要素を宣言する。省略時設定では、データ
は、そのクラスのメソッドによってしかアクセスできな
い。

【００４０】５．methods（メソッド部分） この部分では、このクラスのオブジェクトが応答するこ
とのできるメソッドを宣言する。省略時設定では、この
部分で宣言されるすべてのメソッドは、どのクラス・ク
ライアントからも使用可能である。下記のクラス定義フ
ァイルstudent.cscは、非誘導クラスであるStudentクラ
スを記述したファイルである。

【００４１】Ｄ．メソッドの記述のしかた クラス・メソッドは、クラス・メソッド実装ファイル内
で実装される。クラス定義ファイルのメソッド部分で定
義されたメソッドをすべて実装する必要がある。これら
は、ＳＯＭサポートを提供するどの言語でも実装するこ
とができる。本明細書全体を通して、例となる言語とし
てＣ言語を使用する。ただし、当業者なら、その代りに
どのプログラミング言語も使用できることを理解するで
あろう。Studentのクラス・メソッド実装ファイルstude
nt.cを、以下に示す。

【００４２】このメソッド・コードが、標準Ｃ言語に類
似して見えることに留意されたい。まず、各メソッド
は、その第１パラメータとしてターゲット・オブジェク
トを指すポインタ（somSelf）をとる。このパラメータ
は、クラス定義ファイル内では暗示的であるが、メソッ
ド実装ファイルでは明示される。第２に、各メソッド
は、somThisという名前の内部変数をセットする行から
始まる。somThisは、ＳＯＭヘッダ・ファイル内で定義
されるマクロによって使用される。第３に、ターゲット
・オブジェクトのデータ要素の名前の前に、下線文字"
_"が付けられている。下線付きの名前は、クラス・ヘッ
ダ・ファイル内で定義されるＣ言語のマクロを表す。第
４に、メソッドは、メソッド名の前に下線"_"を置くこ
とによって呼び出される。この下線付きの名前は、メッ
セージ解決策(message resolution)用のマクロを表し、
プログラマがこの処理の詳細を理解しなくてよいように
する。

【００４３】各メソッドの第１パラメータは、必ず、タ
ーゲット・オブジェクトを指すポインタになっている。
これは、下記の、ターゲット・オブジェクトに対してメ
ソッドgetStudentType()を呼び出すメソッドprintStude
ntInfo()に示されている。

【００４４】Ｅ．ＳＯＭを使用する機構 各クラスに関連する１組のファイルがあり、これを以下
で論ずる。これらのファイルは、異なる拡張子を有する
が、いずれもクラス定義ファイル（この例ではStuden
t）と同じファイル名を有する。これらのファイルを以
下で説明する。

【００４５】Studentクラスのファイル <student.csc> − これは、前述のクラス定義ファイ
ルである。

【００４６】<student.sc> − これは、クラス定義フ
ァイルのサブセットである。これには、 .cscファイル
からの、公用(public)であるすべての情報（公用要素に
対するコメントを含む）が含まれる。studentの例で
は、student.scが、データ部分を除くstudent.cscのす
べてを含むことになる。このファイルは、ＳＯＭコンパ
イラによって作成される。

【００４７】<student.h> − これは、そのクラスの
公用メソッドを呼び出し、そのクラスの公用データ要素
にアクセスするのに必要なマクロを含む、有効なＣヘッ
ダ・ファイルである。このファイルは、そのクラスのど
のクライアントにも組み込まれる。このファイルは、Ｓ
ＯＭコンパイラによって作成される。

【００４８】<student.ih> − これは、student.hに
類似しているが、メソッドを実装するのに必要な追加の
情報を含むファイルである。これは、実装者(implement
or)版の.hファイルであり、クラス・メソッド実装ファ
イルに組み込まなければならない。このファイルは、Ｓ
ＯＭコンパイラによって作成されるが、編集してはなら
ない。

【００４９】<student.c> − これは、メソッド実装
態様を含むファイルである。最初にＳＯＭコンパイラに
よって作成され、その後、クラスの実装者によって更新
される。

【００５０】 Ｆ．他のクラスからＳＯＭクラスを作成する方法 クラスを他のクラス用の構成単位として使用するには、
２つの方法がある。２つの方法とは、誘導（または継
承）と構築である。

【００５１】（i）誘導 この例では、GraduateStudentが、その基本クラスまた
は親クラスであるStudentから誘導される。誘導クラス
は、基本クラスの特性をすべて自動的に拾い上げる。誘
導クラスは、新規メソッドを定義し実装することによっ
て、新規の機能を追加することができる。また、誘導ク
ラスは、その基本クラスのメソッドを再定義することが
でき、この処理をオーバーライドと称する。たとえば、
GraduateStudentは、Studentから継承したメソッドに、
setUpGraduateStudent()を追加する。このクラスは、他
の２つの継承されたメソッド、printStudentInfo()とge
tStudentType()をオーバーライドする。このクラスは、
基本クラスStudentから、setUpStudent()とgetStudentI
d()を無変更で継承する。

【００５２】GraduateStudent用のクラス定義ファイ
ル、graduate.cscを、以下に示す。

【００５３】メソッド実装ファイル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); }

【００５４】オーバーライドされたメソッドは、しばし
ば、その親の元のメソッドを呼び出す必要がある。たと
えば、GraduateStudent用のprintStudentInfo()は、ま
ずStudent版のprintStudentInfo()を呼び出してから、G
raduateStudentに特有の情報をプリントアウトする。こ
の場合の構文は、printStudentInfo()メソッドに見られ
るように、"<parent_MethodName>（親＿メソッド名）"
である。

【００５５】所与の基本クラスを使用して、複数の誘導
を行うことができる。クラスUnderGraduateStudentも、
Studentから誘導される。そのクラス定義ファイルundgr
ad.cscを、以下に示す。

【００５６】メソッド実装ファイルundgrad.cを、以下
に示す。

【００５７】（ii）構築 クラスを作成するための第２の技法が、構築である。構
築とは、継承によらずに別のクラスを使用して、クラス
を参照する。構築のよい例が、Studentを指すポインタ
のアレイを含むクラスCourse（課程）である。各ポイン
タは、その課程を履修する特定の学生（Student）のア
ドレスを保持する。Courseは、Studentから構築され
る。Courseのクラス定義ファイルcourse.cscを、以下に
示す。

【００５８】しばしば、特別な処置を取ってクラスのイ
ンスタンス・データを初期設定したいことがある。Cour
seのインスタンスは、少なくともenrollmentデータ要素
を初期設定して、そのアレイ指標が有効な状態で開始す
ることを保証しなければならない。新規オブジェクトを
作成する際には、必ずメソッドsomInit()が呼び出され
る。このメソッドは、SOMObjectから継承され、オブジ
ェクトの初期設定が望まれる時、このメソッドをオーバ
ーライドすることができる。

【００５９】この例は、誘導クラスと基本クラスの間の
「である（is-a）」関係という、継承の興味深い特性を
示している。どの誘導クラスも、基本クラスとみなすこ
とができる。誘導クラスは、基本クラス「である」（"i
s-a"）といわれる。前の例では、GraduateStudentは、S
tudent「であり」（"is-a"）、Studentが期待される場
所であればどこででも使用することができる。その逆は
真ではない。基本クラスは、必ずしも誘導クラスではな
く、よってStudentを無条件にGraduateStudentとして扱
うことはできない。すなわち、アレイstudentListの要
素は、Student、GraduateStudentまたはUnderGraduateS
tudentのいずれかを指すことができる。

【００６０】Courseのメソッド実装ファイルcourse.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] = _instructor[0] = 0; _credit = _capacity = _enrollment = 0; } static void setUpCourse(Course *somSelf, char *code, char *title, char *instructor, 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(-1); _studentList[_enrollment++] = student; return(0); } static void dropStudent(Course *somSelf, char *studentId) { int i; CourseData *somThis = CourseGetData(somSelf); for(i=0; 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=0; i<_enrollment; i++) { _printStudentInfo(_studentList[i]); printf("\n"); } }

【００６１】特にメソッドprintCourseInfo()に留意さ
れたい。このメソッドは、アレイstudentList全体を走
査して、各学生（student）ごとにメソッドprintStuden
tInfo()を呼び出す。このメソッドは、Studentに対して
定義された後に、GraduateStudentとUnderGraduateStud
entの両方によってオーバーライドされる。このアレイ
要素は、これら３つのクラスのどれを指すこともできる
ので、コンパイル時には、ターゲット・オブジェクトの
実際のタイプが何であるかを決定することは不可能であ
り、ターゲット・オブジェクトがStudentか、またはStu
dentから誘導されたなんらかのタイプであるということ
しか決定できない。これらのクラスはそれぞれで、異な
るprintStudentInfo()メソッドを定義するので、ループ
の各パスで、これらのメソッドのうちのどれが呼び出さ
れるのかを決定することは不可能である。これは、完全
にオーバーライド解決策(override resolution)の制御
下にある。

【００６２】Ｇ．ＳＯＭクライアント あるクライアントが１プログラム内でこれら４つのクラ
スをどのように使用できるのかを理解するために、下記
のファイル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", "コンパイラ ", "デビッド・ジョンソン博士", 3, 15); _setUpGraduateStudent(jane,"423538", "ジェーン・ブラウン","Code Optimization","Ph.D."); _setUpUnderGraduateStudent(mark,"399542", "マーク・スミス", "12/17/92"); _addStudent(course, jane); _addStudent(course, mark); _printCourseInfo(course); }

【００６３】クラスは、メソッドclassNameNew()を用い
て実体化(instantiate)される。メソッドclassNameNe
w()は、認識されるクラスごとに、ＳＯＭによって自動
的に定義される。メソッドは、メソッド名の前に下線"
_"を置くことによって呼び出される。その第１パラメー
タは、ターゲット・オブジェクトである。残りのパラメ
ータは、そのメソッドが必要とする追加の情報を示す。
走行時に、クライアント・プログラムは、下記の出力を
与える。

【００６４】このクライアント・プログラム出力は、Un
derGraduateとGraduateStudentという異なる表示スタイ
ルで動作するオーバーライド解決策を示すものである。
あるCourseは、それ自体がStudentのアレイを含んでい
るものと考え、どのStudentでもprintStudentInfo()メ
ソッドに応答することを知っている。しかし、UnderGra
duateが応答するprintStudentInfo()メソッドは、Gradu
ateStudentが応答するprintStudentInfo()メソッドと異
なり、これら２つのメソッドは異なる出力を与える。

【００６５】Ｈ．ＳＯＭのオブジェクト・モデル 図２は、本発明による基本ＳＯＭデータ構造を示す図で
ある。符号２１０は、特定のオブジェクト用の状態デー
タ構造体である。符号２２０の最初のフルワードが、そ
のオブジェクトのメソッド手続きテーブル２４０のアド
レスを保持する。符号２３０で示される状態データ構造
体の残りの部分は、そのオブジェクトに固有の追加情報
を保持する。符号２４０で示されるメソッド手続きテー
ブルは、クラス・オブジェクト・データ構造体のアドレ
ス２４５と、特定のオブジェクト用の様々なメソッドの
アドレス２５０および２６０を保持する。符号２４５の
アドレスは、クラス・オブジェクト・データ構造体２４
８を指す。このオブジェクトと同じクラスのすべてのオ
ブジェクトも、符号２４０で示されるこのメソッド手続
きテーブルを指すアドレスを保持する。これらのオブジ
ェクトにより継承されたすべてのメソッドは、メモリ内
で、そのメソッドの継承元である先祖クラス（親クラ
ス）の符号２４０で示されるメソッド手続きテーブル内
の位置と同じオフセットの位置に、メソッド手続きアド
レスを有する。

【００６６】２つのメソッド手続きに対する命令列を含
むコンピュータ・メモリのブロックのアドレスが、符号
２５０および２６０で示されている。符号２７０および
２８０は、コンピュータ・メモリ内の、符号２５０およ
び２６０で示されたアドレスで指定される特定のメソッ
ド手続きの命令列を含む位置を表す。

【００６７】Ｉ．ＳＯＭ基本クラス ＳＯＭオブジェクト・モデルの多くは、ＳＯＭ基本サポ
ートの一部である３つのクラスによって実装される。以
下で、これらのクラスを手短に説明する。

【００６８】SOMObject − このクラスは、すべての
ＳＯＭクラスのルート・クラスである。どのクラスも、
SOMObjectの子孫になっていなければならない。すべて
のクラスがSOMObjectの子孫であるから、これらのクラ
スはすべて、SOMObjectによって定義されるメソッドを
継承し、したがってサポートする。SOMObjectのメソッ
ドは、どのＳＯＭクラスのメソッドとも同様に、SOMObj
ectの子孫であるクラスによってオーバーライドでき
る。

【００６９】SOMClass − このクラスは、すべてのＳ
ＯＭメタクラスのルート・メタクラスである。メタクラ
スとは、そのインスタンスがクラス・オブジェクトであ
るクラスである。SOMClassは、新規クラス・オブジェク
トを作成できるようにするメソッドを提供する。

【００７０】SOMClassMgr − このクラスは、クラス
・オブジェクトを管理するＳＯＭに基づくプログラムで
単一のオブジェクトを作成するのに使用される。

【００７１】この３つのＳＯＭ基本クラスを、以下で定
義する。

【００７２】＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＝＝＝＝＝＝＝＝＝ （ｉ）SOMObject これは、ＳＯＭルート・クラスであり、すべてのＳＯＭ
クラスは、SOMObjectの子孫になっていなければならな
い。SOMObjectは、インスタンス・データを有しておら
ず、したがって、その子孫になるためのインスタンスご
とのコストは、存在しない。

【００７３】SOMObjectは、下記のメソッドを有する。

【００７４】メソッド： somInit パラメータ： somSelf 戻り値： void 説明：selfを初期設定する。SOMObjectのインスタンス
は、インスタンス・データを有さないので、初期設定す
べきものはなく、このメソッドを呼び出す必要はない。
これは、初期設定を必要とするサブクラス間の整合性を
誘発するために設けられる。

【００７５】somInitは、オブジェクト作成の副作用と
して（すなわち、somNewによって）自動的に呼び出され
る。この作用を望まない場合、ユーザは、somInitを呼
び出さないユーザ自身の版のsomNewを（ユーザ記述のメ
タクラス内で）供給することができる。

【００７６】このメソッドをオーバーライドする時に
は、ユーザ自身の初期設定を行う「前」に、必ず親クラ
ス版のこのメソッドを呼び出さなければならない。

【００７７】メソッド： somUninit パラメータ： somSelf 戻り値： void 説明：（selfの初期設定解除） SOMObjectのインスタ
ンスは、インスタンス・データを有さないので、初期設
定解除すべきものはなく、このメソッドを呼び出す必要
はない。これは、初期設定解除を必要とするサブクラス
間の整合性を誘発するために設けられる。

【００７８】動的に割り振られた記憶域など、必要なも
のを何でもクリーンアップするのにこのメソッドを使用
する。ただし、このメソッドは、そのオブジェクト・イ
ンスタンスに実際に割り当てられた記憶域の解放は行わ
ない。このメソッドは、somFreeを補足するものとして
設けられる。somFreeは、動的に割り振られたオブジェ
クトに関連する記憶域を解放する。通常は、somFreeを
呼び出すだけで、このsomFreeがsomUninitを呼び出す。
しかし、somRenew（SOMClassの定義を参照のこと）を使
用してオブジェクト・インスタンスを作成した場合に
は、somFreeを呼び出すことはできず、明示的にsomUnin
itを呼び出さなければならない。

【００７９】このメソッドをオーバーライドする時に
は、ユーザ自身の初期設定解除を行った「後に」、必ず
親クラス版のこのメソッドを呼び出さなければならな
い。

【００８０】メソッド： somFree パラメータ： somSelf 戻り値： void 説明：selfがsomNew（または、somNewを使用する別のク
ラス・メソッド）によって作成されたとの前提で、self
に関連する記憶域を解放する。その後は、selfに対する
参照は行われないはずである。記憶域を解放する前に、
selfに対してsomUninitを呼び出す。

【００８１】このメソッドは、somNew（SOMClassの定義
を参照のこと）によって作成されたオブジェクトに対し
てのみ呼び出すことができ、somRenewによって作成され
たオブジェクトに対しては、絶対に呼び出してはならな
い。

【００８２】このメソッドをオーバーライドする必要は
ないはずである。（その代わりにsomUninitをオーバー
ライドする）

【００８３】メソッド： somGetClassName パラメータ： somSelf 戻り値： Zstring 説明：ＮＵＬＬで終端する文字列として、このオブジェ
クトのクラスの名前を指すポインタを返す。このメソッ
ドは、クラス・オブジェクトのメソッド（somGetName）
を呼び出して名前を取得するだけなので、このメソッド
をオーバーライドする必要はないはずである。

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

【００８５】メソッド： somGetSize パラメータ： somSelf 戻り値： integer4 説明：このインスタンスのサイズ（バイト単位）を返
す。

【００８６】メソッド： somRespondTo パラメータ： somSelf, somId Mid 戻り値： int 説明：指示されたメソッドがこのオブジェクトのクラス
によってサポートされる場合は１（真）、そうでない場
合は０（偽）を返す。

【００８７】メソッド： somIsA パラメータ： somSelf, SOMClass *Aclassobj 戻り値： int 説明：selfのクラスがAclassobjの子孫クラスである場
合は１（真）、そうでない場合は０（偽）を返す。注
意：このメソッドでは、クラス・オブジェクトは、それ
自体の子孫であるとみなされる。

【００８８】メソッド： somIsInstanceOf パラメータ： somSelf, SOMClass *Aclassobj 戻り値： int 説明：selfが指定されたAclassobjのインスタンスであ
る場合は１（真）、そうでない場合は０（偽）を返す。

【００８９】（ａ）動的オブジェクト・モデルをサポー
トするSOMObjectメソッド これらのメソッドは、非常に動的な定義域を、ＳＯＭオ
ブジェクト・プロトコル境界に束縛するのを簡単にす
る。これらのメソッドは、適当なメソッド手続きを決定
し、その後、指定された引数を用いてそれを呼び出す。
このクラスで提供されるこれらのメソッドの省略時実装
態様は、名前によってメソッドを表引きし(look up)、
それを呼び出すだけである。しかし、他のクラスでは、
希望する任意の形の表引きを実装することが選択でき
る。たとえば、ＣＬＯＳ形のメソッド・ソリューション
を使用する、これらのメソッドの実装態様を提供するこ
ともできる。それが可能な定義域に対しては、一般に、
ディスパッチ・メソッドを介するよりも、それらのメソ
ッドを直接に呼び出すほうがはるかに高速である。しか
し、すべてのメソッドが、ディスパッチ・メソッドを介
して到達可能である。ＳＯＭは、これらのメソッド呼出
しを包む(wrap)ための小さな１組の外部手続きを提供
し、その結果呼出し元がメソッド・ソリューションを絶
対に必要としなくなる。

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

【００９１】注意：戻り値の形によって、メソッドの定
義は異なる。これによって、戻り値を運ぶために追加パ
ラメータが必要となった場合にある種の定義域で発生す
るはずのメモリ管理の問題が回避される。ＳＯＭは、下
記の４つのファミリを除いて戻り値をサポートしない。
あるファミリ（Integer（整数）など）内では、ＳＯＭ
は、最大の数だけをサポートする。

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

【００９３】メソッド： somDispatchL パラメータ： somSelf, somId methodId, somId descri
ptor 戻り値： integer4 説明：整数データを返す通常の方式で４バイトの数量を
返す。この４バイトの数量は、もちろん、整数以外でも
よい。

【００９４】メソッド： somDispatchA パラメータ： somSelf, somId methodId, somId descri
ptor 戻り値： void * 説明：データ構造体アドレスを返す通常の方式でデータ
構造体アドレスを返す。

【００９５】メソッド： somDispatchD パラメータ: somSelf, somId methodId, somId descrip
tor 戻り値： float8 説明：浮動小数点データを返す通常の方式で８バイトの
数量を返す。

【００９６】（ｂ）開発を支援するSOMObjectメソッド このグループのメソッドは、プログラム開発をサポート
するために設けられる。これらのメソッドは、ほとんど
の開発状況で利用しやすい形で定義されている。ただ
し、ある種の状況では、それらの入出力機能をカストマ
イズする必要のある場合がある。非常に可搬性を有する
形でこのカストマイズを行えるように試みたが、カスト
マイズ動作には関数パラメータの受け渡しが必要なの
で、すべての状況でカストマイズ動作を直接に実行でき
るわけではない。この手法を選択したのは、これによっ
てプラットフォーム中立の高い柔軟性が得られるからで
あり、開発サポートのどの提供者でも、その提供者に特
有の開発環境に必要なカストマイズを提供することが妥
当だと感じるであろうと思われる。

【００９７】この選択された手法は、文字出力ルーチン
に依拠している。外部変数SOMOutCharRoutineが、この
ルーチンを指す。ＳＯＭ環境は、ほとんどの開発環境で
作動するはずの（標準出力ストリームに書き込む）この
ルーチンの実装態様を提供する。しかし、ある開発状況
で、SOMOutCharRoutineに新規の値を割り当て、これに
よって出力処理を再定義することが可能である。ＳＯＭ
は、この割当てを行うための特別なサポートを提供しな
い。

【００９８】メソッド： somPrintSelf パラメータ： somSelf 戻り値： SOMAny * 説明：SOMOutCharRoutineを使って、このオブジェクト
に関する識別情報を含む短い文字列を書く。省略時実装
態様は、そのオブジェクトのクラス名と、メモリ内のそ
のアドレスを与えるだけである。selfが返される。

【００９９】メソッド： somDumpSelf パラメータ： somSelf, int level 戻り値： void 説明：SOMOutCharRoutineを使って、このオブジェクト
とその現在の状態の詳細な記述を書く。levelは、複合
オブジェクトを記述するための入れ子レベルを示し、０
以上でなければならない。記述の各行の先頭に、必ず2*
level個の空白が付く。

【０１００】このルーチンは、実際には、クラスなど全
体としてのオブジェクトに関係するデータを書き込み、
somDumpSelfIntを使ってそのオブジェクトの現在の状態
を記述するだけである。この手法を用いると、複合オブ
ジェクトの可読性のある記述を組み立てることができ
る。

【０１０１】一般に、このメソッドをオーバーライドす
る必要はなく、オーバーライドする場合には、一般に、
完全に置き換える必要がある。

【０１０２】メソッド： somDumpSelfInt パラメータ： somSelf, int level 戻り値： void 説明：SOMOutCharRoutineを使って、このオブジェクト
の現在の状態を書き出す。一般に、このメソッドは、オ
ーバーライドの必要がある。オーバーライドする時に
は、まず親クラスの形のこのメソッドを呼び出し、その
後、ユーザ・クラスのインスタンス・データの記述を書
き出す。これによって、そのオブジェクトのルートの先
祖クラスからその特定のクラスまでの、そのオブジェク
トのすべてのインスタンス・データが記述される。

【０１０３】（ii）SOMClass これは、ＳＯＭメタクラスである。すなわち、このクラ
スのインスタンスは、クラス・オブジェクトである。Ｓ
ＯＭ環境が作成される時に、外部名SOMClassClassData.
classObjectを有するこのクラスのインスタンスが、１
つ作成される。このクラス・オブジェクトは、それがそ
れ自体のクラス・オブジェクトであるのでユニークであ
る。すなわち、SOMClassClassData.classObject == _so
mGetClass(SOMClassClassData.classObject)である。こ
のクラスは、ＳＯＭオブジェクトの新規インスタンスを
作成するのに使用されるメソッド、somNewとsomRenewを
導入する。SOMClassClassData.classObjectにsomNewを
適用すると、新規クラス・オブジェクトが作られ、その
後、この新規クラス・オブジェクトを特定の新規クラス
になるように初期設定することができる。SOMClassは、
どんなＳＯＭクラスとも同様に、サブクラスに分けるこ
とができる。SOMClassのサブクラスは、新規のメタクラ
スであり、SOMClassClassData.classObjectによって作
成されるのとは異なる実装態様を有するクラス・オブジ
ェクトを生成することができる。

【０１０４】SOMClassはSOMObjectの子孫である。SOMCl
assでは、以下のメソッドが定義される。

【０１０５】メソッド： somNew パラメータ： somSelf 戻り値： SOMAny * 説明：このクラスのインスタンスを作成する。SOMClass
ClassData.classObjectまたは他のメタクラス・オブジ
ェクトに適用された時には、新規のクラス・オブジェク
トを作成する。通常のクラス・オブジェクトに適用され
た時は、そのクラスのインスタンスを作成する。

【０１０６】メソッド： somRenew パラメータ： somSelf, SOMAny *obj 戻り値： SOMAny * 説明：このクラスのインスタンスを作成するが、そのオ
ブジェクトのために新規の空間を割り振るのではなく、
objが指す空間を使用する。注意：objが十分な空間を指
していることを確認するテストは行われない。objが返
されるが、その時点でobjは有効な初期設定済みのオブ
ジェクトを指すポインタになっている。

【０１０７】メソッド： somInitClass パラメータ： somSelf, Zstring className, SOMAny *p
arentClass,integer4 instanceSize, int maxStaticMet
hods, integer4 majorVersion,integer4 minorVersion 戻り値： void 説明：selfを初期設定する。

【０１０８】parentClassは、このクラスの親（または
親クラス）である。これはＮＵＬＬであってもよいが、
その場合は、SOMObject（実際には、SOMObjectのクラス
・オブジェクトであるSOMObjectClassData.classObjec
t）が省略時の値になる。親クラスが指定される場合、
そのクラス・オブジェクトを指すポインタが必要なの
で、その親クラスが既に作成されていなければならな
い。

【０１０９】instanceSizeは、このクラスに必要な空間
とちょうど同じにしなければならないが、親クラス（存
在するならば）の空間要件を考慮する必要はない。

【０１１０】maxStaticMethodsは、このクラスによって
定義される静的メソッドの数とちょうど同じにしなけれ
ばならないが、親クラスのメソッド（が存在する場合、
それ）をこのメソッドでオーバーライドする場合でも、
親クラス・メソッドを考慮する必要はない。

【０１１１】majorVersionは、クラス定義のこの実装の
主バージョン番号を示し、minorVersionは、その副バー
ジョン番号を示す。

【０１１２】メソッド： somClassReady パラメータ： somSelf 戻り値： void 説明：このメソッドは、クラスの静的初期設定がすべて
完了した時に呼び出される。省略時の実装態様は、新規
に構築されたクラスをSOMClassMgrに登録するだけであ
る。メタクラスでは、このメソッドをオーバーライドし
て、望みのどんな形でクラス構築シーケンスを増補して
もよい。

【０１１３】メソッド： somGetName パラメータ： somSelf 戻り値： Zstring 説明：このオブジェクトのクラス名を、ＮＵＬＬで終端
する文字列として返す。

【０１１４】メソッド： somGetParent パラメータ： somSelf 戻り値： SOMClass * 説明：selfの親クラスが存在する場合はその親クラス
を、存在しない場合はＮＵＬＬを返す。

【０１１５】メソッド： somGetClassData パラメータ： somSelf 戻り値： somClassDataStructure * 説明：静的構造体<className>ClassData（<className>
にはクラス名が入る）を指すポインタを返す。

【０１１６】メソッド： somSetClassData パラメータ： somSelf, somClassDataStructure *cds 戻り値： void 説明：クラスのポインタを、静的構造体<className>Cla
ssDataにセットする。

【０１１７】メソッド： somDescendedFrom パラメータ： somSelf, SOMClass *Aclassobj 戻り値： int 説明：selfがAclassobjの子孫クラスである場合は１
（真）、そうでない場合は０（偽）を返す。注意：クラ
ス・オブジェクトは、このメソッドでは、それ自体の子
孫であるとみなされる。

【０１１８】メソッド： somCheckVersion パラメータ： somSelf, integer4 majorVersion, integer4 minorVersion 戻り値： int 説明：このクラスの実装が、指定された主バージョン番
号および副バージョン番号に対する互換性を有する場合
は１（真）、そうでない場合は０（偽）を返す。ある実
装態様が、同一の主バージョン番号と、minorVersion以
上の副バージョン番号を有する場合、その実装態様は指
定されたバージョン番号に対する互換性を有する。主／
副バージョン番号対（０、０）は、どのバージョンにも
一致するものとみなされる。このメソッドは、通常、動
的にロードされたクラス定義がそれを使用するアプリケ
ーションに対する互換性を有することを検証するため
に、クラス・オブジェクトを作成した直後に呼び出され
る。

【０１１９】メソッド： somFindMethod パラメータ： somSelf, somId methodId, somMethodProc **m 戻り値： int 説明：methodIdに関連するこのクラス用のメソッド手順
を見つけ、mをそれにセットする。そのメソッド手順が
直接に呼び出せる時は１（真）、そのメソッド手順がデ
ィスパッチ関数である時は０（偽）を返す。

【０１２０】そのクラスが指定されたメソッドをサポー
トしない場合は、mがＮＵＬＬにセットされ、戻り値は
無意味である。

【０１２１】ディスパッチ関数が返されても、あるクラ
スが指定されたメソッドをサポートすることの保証には
ならない。ディスパッチが失敗することもある。

【０１２２】メソッド： somFindMethodOk パラメータ： somSelf, somId methodId, somMethodProc **m 戻り値： int 説明：メソッドがサポートされない場合に、エラーが発
生し実行が停止する点を除いて、somFindMethodと同様
である。

【０１２３】メソッド： somFindSMethod パラメータ： somSelf, somId methodId 戻り値： somMethodProc * 説明：指示されたメソッドを見つけ、そのメソッド手順
を指すポインタを返す。このメソッドは、このクラス用
に定義された静的メソッドでなければならない。メソッ
ドがこのクラスに関しても（静的メソッドとしては、ま
たは全く）定義されていない場合は、ＮＵＬＬポインタ
を返す。

【０１２４】メソッド： somFindSMethodOk パラメータ： somSelf, somId methodId 戻り値： somMethodProc * 説明：メソッドがこのクラス用に定義されていない場合
に、エラーが発生する点を除いて、somFindSMethodと同
様である。

【０１２５】メソッド： somSupportsMethod パラメータ： somSelf, somId Mid 戻り値： int 説明：指示されたメソッドをこのクラスがサポートする
場合は１（真）、そうでない場合は０（偽）を返す。

【０１２６】メソッド： somGetNumMethods パラメータ： somSelf 戻り値： int 説明：継承されたメソッド（静的と動的の両方）を含
む、このクラスが現在サポートしているメソッドの数を
返す。

【０１２７】メソッド： somGetInstanceSize パラメータ： somSelf 戻り値： integer4 説明：selfの１インスタンスの全体サイズを返す。self
のインスタンスは、すべて同一のサイズを有する。

【０１２８】メソッド： somGetInstanceOffset パラメータ： somSelf 戻り値： integer4 説明：このクラスに属するインスタンス・データの、こ
のオブジェクトの本体部分内でのオフセットを返す。

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

【０１３０】メソッド： somGetNumStaticMethods パラメータ： somSelf 戻り値： int 説明：このクラスが有する静的メソッドの数を返す。こ
れは、子クラスのメソッド・テーブルを初期設定する際
に、子クラスによって使用される。

【０１３１】メソッド： somGetPClsMtab パラメータ： somSelf 戻り値： somMethodTab * 説明：このクラスの親クラスのメソッド・テーブルを指
すポインタを返す。このクラスがルート・クラス（SOMO
bject）である場合は、ＮＵＬＬを返す。

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

【０１３３】メソッド： somAddStaticMethod パラメータ： somSelf, somId methodId, somId method
Descriptor,somMethodProc *method, somMethodProc *r
edispatchStub,somMethodProc *applyStub 戻り値： somMOffset 説明：指示されたメソッドを追加またはオーバーライド
し、クラス・データ構造体内でのこのメソッド名のオフ
セット値をセットするのに使用しなければならない値を
返す。

【０１３４】methodDescriptorは、SOMObjectのクラス
定義で定義されるsomcGetNthMethodInfoに記述される、
このメソッドの呼出しシーケンスを記述する文字列のso
mIdである。

【０１３５】methodは、このメソッドに対する実際のメ
ソッド手順である。

【０１３６】redispatchStubは、methodと同じ呼出しシ
ーケンスを有する手順であって、そのメソッドをこのク
ラスのディスパッチ関数のうちの１つに再ディスパッチ
する。

【０１３７】applyStubは、標準可変引数リスト・デー
タ構造体から誘導される引数を用いてmethodを呼び出す
ことによって、そのデータ構造体をとり、それをターゲ
ット・オブジェクトに適用する手順である。その呼出し
シーケンスは、SOMObjectで定義されるディスパッチ・
メソッドの呼出しシーケンスと同じである。このスタブ
は、一部のクラスで使用されるディスパッチ・メソッド
のサポートに使用される。ディスパッチ関数がこのよう
な機能を必要としないクラスでは、このパラメータはＮ
ＵＬＬでよい。

【０１３８】メソッド： somOverrideSMethod パラメータ： somSelf, somId methodId,somMethodProc
*method 戻り値： void 説明：このメソッドは、そのクラスの親クラスが既にこ
のメソッドをサポートしていることがわかっている時、
somAddStaticMethodまたはsomAddDynamicMethodの代わ
りに使用できる。この呼出しは、他の呼出しに必要なメ
ソッド記述子とスタブ・メソッドを必要としない。

【０１３９】メソッド： somGetMethodOffset パラメータ： somSelf, somId methodId 戻り値： integer4 説明：指定されたメソッドが静的メソッドである場合は
そのメソッドのメソッド手順テーブル内でのオフセット
を、そうでない場合は０を返す。この値は、このクラス
のデータ構造体内でのオフセット値をセットするのに使
用される。このメソッドを使用する必要があるのは、あ
るクラスを使用して、継承するメソッドを定義する時だ
けである。

【０１４０】メソッド： somGetApplyStub パラメータ： somSelf, somId methodId 戻り値： somMethodProc * 説明：指定されたメソッドに関連する適用スタブ（appl
y stub）を返す。そのメソッドがこのクラスによってサ
ポートされない場合には、ＮＵＬＬを返す。適用スタブ
とは、固定呼出しシーケンス、すなわち(SOMAny *self,
somId methodId, somId descriptor, ap_list ap)を用
いて呼び出される手順である。ただし、apは、そのメソ
ッドに渡される実際の引数リストを含むvarargsデータ
構造体である。適用スタブは、この呼出しをそれに関連
するメソッドに転送し、その後、そのメソッドによって
生成されるすべての結果を返す。

【０１４１】（iii）SOMClassMgr SOMClassMgrは、SOMObjectの子孫である。SOMObjectで
は、下記のメソッドが定義される。

【０１４２】メソッド： somFindClsInFile パラメータ： somSelf, somId classId, int majorVers
ion,int minorVersion, Zstring file 戻り値： SOMClass * 説明：指定されたクラスのクラス・オブジェクトを返
す。この結果、動的ロードが行われることがある。その
クラスが既に存在する場合はfileを無視し、そうでない
場合は、fileを使ってそのクラスを見つけ、動的にロー
ドする。主／副バージョン番号（majorVersion、minorV
ersion）の値が０の時は、バージョン検査は行われな
い。

【０１４３】メソッド： somFindClass パラメータ： somSelf, somId classId, int majorVers
ion,int minorVersion 戻り値： SOMClass * 説明：指定されたクラスのクラス・オブジェクトを返
す。この結果、動的ロードが行われることがある。somL
ocateClassFileを使って、そのクラスのコードが常駐す
るファイルの名前を取得し、その後、somFindClsInFile
を使用する。

【０１４４】メソッド： somClassFromId パラメータ： somSelf, somId classId 戻り値： SOMClass * 説明：所与のId（識別子）に対して、そのクラス・オブ
ジェクトが既に存在するならば、それを見つける。クラ
スのロードは行わない。クラス・オブジェクトがまだ存
在していない場合は、ＮＵＬＬを返す。

【０１４５】メソッド： somRegisterClass パラメータ： somSelf, SOMClass *classObj 戻り値： void 説明：クラス・マネジャに、指定されたクラスが導入済
みであることを知らせ、そのクラス・オブジェクトのあ
る場所を伝える。

【０１４６】メソッド： somUnregisterClass パラメータ： somSelf, SOMClass *classObj 戻り値： int 説明：クラス・ファイルをアンロードし、ＳＯＭ登録簿
からそのクラスを削除する。

【０１４７】メソッド： somLocateClassFile パラメータ： somSelf, somId classId, int majorVers
ion,int minorVersion 戻り値： Zstring 説明：サブクラスによって供給される実際の実装。省略
時の実装態様は、ファイル名としてクラス名を返す。サ
ブクラスでは、バージョン番号情報を使って、ファイル
名の誘導を助けることもできる。

【０１４８】メソッド： somLoadClassFile パラメータ： somSelf, somId classId, int majorVers
ion,int minorVersion, Zstring file 戻り値： SOMClass * 説明：クラスのコードをロードし、クラス・オブジェク
トを初期設定する。

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

【０１５０】メソッド： somGetInitFunction パラメータ： somSelf 戻り値： Zstring 説明：クラスのコード・ファイル内の初期設定関数の名
前を供給する。省略時の実装態様は、(*SOMClassInitFu
ncName)()を返す。

【０１５１】メソッド： somMergeInto パラメータ： somSelf, SOMObject *targetObj 戻り値： void 説明：受取側オブジェクトからのSOMClassMgr登録簿情
報をtargetObjに組み合わせる。targetObjは、SOMClass
Mgrのインスタンスであるか、またはそのサブクラスの
うちの１つのインスタンスである必要がある。この動作
の完了時に、targetObjは、受取側オブジェクトの置換
物として機能できなければならない。動作の終了時に、
受取側オブジェクト（その時点で、新規に初期設定解除
された状態になっている）が解放される。このメソッド
をオーバーライドするサブクラスは、オブジェクトのう
ちそのサブクラスの部分を同様に転送し、最終ステップ
として親にこのメソッドを渡さなければならない。受取
側オブジェクトが、グローバル変数SOMClassMgrObject
から指される区別されたインスタンスである場合には、
targetObjを指すようにSOMClassMgrObjectを再割当てす
る。

【０１５２】Ｊ．オブジェクト名の管理 本発明は、各クラスの実装に関連する特殊な手続きを介
して、実行時にクラス・メソッド・テーブルを初期設定
すること、および１組のメソッド・オフセットを、外部
的に名前が付けられた単一のクラス・データ構造体(cla
ss data structure)に集めることによって、１クラスの
すべてのメソッドに一義的な外部名を必要とする従来の
オブジェクト指向技法に対して改良されている。この改
良によって、外部変数の大きなリストを管理する複雑さ
が軽減され、一義的な名前を複数生成する問題（名前マ
ングリング(name mangling)問題と称する）が軽減さ
れ、メモリ要求が軽減され、生成された実行モジュール
のロード時間が短縮される。

【０１５３】図３は、本発明によるＳＯＭクラス・デー
タ構造を示す図である。符号３１０は、図２の符号２４
８に示したクラス・オブジェクト・データ構造体を指す
ポインタを表す。符号３２０は、図２の符号２４０に示
したメソッド手続きテーブル内でのオフセット、また
は、図２の符号２３０に示したオブジェクトの状態デー
タ構造体内でのオフセットを表す。同様に、符号３３０
はメソッド手続きテーブル内での追加オフセットを、符
号３４０は状態データ構造体内での追加オフセットを表
す。このクラスで最初に定義される追加メソッド、また
はクラスの解放順序(Release Order)部分に記述される
が当該クラスの先祖クラスの１つによって定義されるメ
ソッド、もしくは当該クラスによって定義される公用イ
ンスタンス変数については、省略記号と符号３５０の"
Ｎ＋１"で表される、当該クラスに関連するオフセット
を表した同様のエントリが、クラス・データ構造体内に
ある。追加のエントリが必要なのは、最初のエントリ
が、図２のクラス・オブジェクト・データ構造体２４８
を指すポインタを表すからである。

【０１５４】クラス・データ構造体内の値の順序は、そ
のクラスのＯＩＤＬファイルの解放順序(Rrelease Orde
r)部分での対応するメソッドまたは公用インスタンス変
数の順序によって決まる。そのクラスで定義されている
が、解放順序部分には記述されていないメソッドまたは
公用データ・メンバの順序は、解放順序部分に記述され
たものの後に、クラスのＯＩＤＬファイルに現れる順に
なる。

【０１５５】Ｋ．オブジェクト・インターフェース定義
言語（ＯＩＤＬ） 本発明は、言語依存のオブジェクト定義を、すべての言
語用のオブジェクト・サポートを提供する中立の１組の
情報として再定義する。この１組の中立の情報を、ＳＯ
Ｍでは、オブジェクト・インターフェース定義言語（Ｏ
ＩＤＬ）定義と称する。ＳＯＭのＯＩＤＬは、種々のプ
ログラミング言語がＳＯＭのオブジェクトおよびその定
義（クラスと称する）を使用し提供できるようにする種
々の束縛ファイル(binding file)を生成するための基礎
を提供する。各ＯＩＤＬファイルでは、ＳＯＭオブジェ
クトのクラスへの完全なインターフェースが定義され
る。

【０１５６】ＯＩＤＬファイルは、言語が異なれば異な
る形式になる。異なる形式にすることによって、ＳＯＭ
コンパイラがクラスを構築するためのサポートを提供で
きるように、言語に固有の追加情報をクラスの実装側が
指定できるようになる。これらの異なる形式はそれぞ
れ、あるクラスを使用するためにユーザが知らなければ
ならない正確な情報を指定する共通の核言語を共用す
る。ＳＯＭコンパイラの機能の１つに、クラス定義の共
通核部分の抽出がある。したがって、クラスの実装側
は、あるクラス用の言語固有のＯＩＤＬファイルを保守
することができ、必要に応じて、ＳＯＭコンパイラを使
って言語中立の核定義(language-neutral corefile)を
作成することができる。

【０１５７】この節では、Ｃ言語プログラミングをサポ
ートするための拡張部分を含むＯＩＤＬについて述べ
る。上述したように、ＯＩＤＬファイルは、ＳＯＭコン
パイラによってコンパイルされて、言語固有またはユー
ザ固有の１組の束縛ファイルが作成される。

【０１５８】ＳＯＭコンパイラは、Ｃ言語用の７つの異
なるファイルを作成する。 ・あるクラスを使用する複数のプログラム用の公用ヘッ
ダ・ファイル。クラスの使用には、そのクラスのインス
タンス・オブジェクトの作成、インスタンス・オブジェ
クトに対するメソッドの呼出し、およびそのクラスのサ
ブクラス化による新規クラスの作成が含まれる。 ・私用ヘッダ・ファイル。これは、そのクラスが有しう
るあらゆる私用メソッドへの使用上の束縛を提供する。 ・実装ヘッダ・ファイル。これは、そのクラスの実装を
サポートするためのマクロその他の材料を提供する。 ・実装テンプレート。これは、クラス提供者(provider)
が後で編集することのできる、クラスの実装のアウトラ
インを提供する。 ・言語中立の核定義。 ・私用言語中立核ファイル。これは、クラス・インター
フェースの私用部分を含む。 ・ＯＳ／２.ＤＥＦファイル。これは、ＯＳ／２のＤＬ
Ｌの形でクラスをパッケージ化するのに使用できる。

【０１５９】ＯＩＤＬファイルは、下記の部分を含むこ
とができる。 ・Include（組込み）部分 ・Class（クラス）部分 ・Release Order（解放順序）部分 ・Metaclass（メタクラス）部分 ・Parent Class（親クラス）部分 ・Passthru（パススルー）部分 ・Data（データ）部分 ・Methods（メソッド）部分

【０１６０】Include（組込み）部分 これは必須部分であり、１つのInclude文を含む。このI
nclude文は、このクラスの親クラスのクラス・インター
フェース定義、そのクラスがメタクラスを指定する場合
にはそのメタクラス、および１つまたは複数の私用メソ
ッドがこのクラスによってオーバーライドされるあらゆ
る先祖クラスの私用インターフェース・ファイルがどこ
にあるかをコンパイラに伝える、ＯＩＤＬ前処理プログ
ラムに対する指令である。

【０１６１】Class（クラス）部分 これは必須部分であり、クラスを導入し、その名前と属
性を与え、任意選択としてそのクラス全体の記述を与え
る。

【０１６２】Release Order（解放順序）部分 これは任意選択部分であり、１つのRelease Order文を
含む。このRelease Order文は、コンパイラに、指定さ
れた順序で項目が配列されたいくつかのクリティカル・
データ構造を強制的に構築させる。これによって、この
クラスを使用するプログラムを再コンパイルする必要な
く、クラス・インターフェースとクラス実装が生成でき
るようになる。

【０１６３】解放順序は、すべてのメソッド名およびす
べての公用データ項目に適用される。あるメソッドや公
用データ項目の解放順序が指定されない場合には、それ
らの省略時値は、ＯＩＤＬファイルに出現する順序に基
づく実装固有の順序になる。新規の公用データ項目また
はメソッドを導入すると、他の公用データ項目またはメ
ソッドの省略時順序が変更される可能性がある。この場
合には、そのクラスを使用するプログラムを再コンパイ
ルすることが必要になる。

【０１６４】Metaclass（メタクラス）部分 これは任意選択部分であり、そのクラスのメタクラスを
指定し、その名前を与え、任意選択として、そのメタク
ラスの理由の記述またはこのクラスのインターフェース
での役割に関する他のコメントを与える。メタクラスを
指定する場合には、Include部分に定義を組み込まなけ
ればならない。メタクラスが指定されない場合は、この
クラスの親クラスのメタクラスが使用される。

【０１６５】あるクラスのメタクラスは、Data部分のク
ラス属性とMethod部分のクラス属性を組み合わせて使用
することによって、暗示的に定義することもできる。こ
れらの属性のどちらかを使用する場合には、メタクラス
部分を省略しなければならない。この場合、暗示のメタ
クラスは、親クラスのメタクラスのサブクラスになる。

【０１６６】Parent Class（親クラス）部分 これは必須部分であり、そのクラスの親クラスの名前を
示すこと、および選択的にこのクラスのインターフェー
スでの親クラスの役割の記述を示すことによって、その
クラスの親クラスを指定する。

【０１６７】Passthru（パススルー）部分 これは任意選択部分であり、コンパイラによって様々な
束縛ファイルに渡されるコードのブロックを提供する。
渡される情報の内容は、コンパイラによって無視され
る。パススルー行に含まれるコメントも、修正なしに処
理される。

【０１６８】Data（データ）部分 これは任意選択部分であり、このクラス用のインスタン
ス変数をリストする。この部分は、一般に、言語固有の
版のクラス・インターフェース定義（.CSCファイル）だ
けに存在する。ただし、そのクラスが公用インスタンス
変数を含む場合には、この部分が、公用形式のクラス・
インターフェース定義中に存在しなければならない。こ
れらの変数を記述するには、ＡＮＳＩ Ｃの構文を使用
する。

【０１６９】Methods（メソッド）部分 これは任意選択部分であり、このクラスによってサポー
トされるメソッドをリストする。各メソッドの呼出しシ
ーケンスを定義するには、ＡＮＳＩ Ｃの関数プロトタ
イプ構文を使用する。

【０１７０】Ｌ．ＳＯＭコンパイラ ＳＯＭコンパイラは、ＳＯＭのクラスのＯＩＤＬソース
定義を、特定のプログラミング言語に適した１組の束縛
に変換する。ＯＳ／２ ２．０ツールキットと共に供給
されるＳＯＭコンパイラは、Ｃプログラミング言語用の
完全な１組の束縛を生成する。

【０１７１】このコンパイラは、事前コンパイル段と発
行(emission)段の２段階で動作する。第１段では、事前
コンパイラが、ユーザ供給のクラス定義を読み取り、分
析し、２進クラス情報、コメントおよびパススルー行を
含む中間出力ファイルを作成する。第２段では、１つま
たは複数の発行プログラム(emitter program)が走行し
て、適当な言語の束縛ファイルを作成する。２つの追加
プログラムが、ＳＯＭ事前コンパイラ段用の前処理プロ
グラムとして働く。これらすべてのプログラムの順序付
けと実行は、ＳＯＭコンパイラによって指令される。

【０１７２】発行プログラムからの出力と、このクラス
のメソッド用にユーザが提供した論理を、その後、Ｃコ
ンパイラによってコンパイルし、ＯＳ／２リンカによっ
てリンクして、ロード可能モジュールを作成する。ロー
ド可能モジュールは、自己完結型ファイルにパッケージ
化するか、あるいはＤＬＬ内に置いて、このクラスを多
くのプログラムから使用できるようにすることができ
る。

【０１７３】図４を参照すると、末端ブロック４００か
ら開始し、機能ブロック４０４に直接移って、そこでＳ
ＯＭ言語中立オブジェクト・インターフェース定義（Ｏ
ＩＤＬ）４０２が、ＳＯＭ ＯＩＤＬコンパイラ４０４
に入力される。ＳＯＭ ＯＩＤＬコンパイラは、ターゲ
ット言語発行プログラム４１０への入力としてのコード
生成処理を簡単にするため、ＯＩＤＬ内のオブジェクト
定義を解析して正規形式４０６にする。ターゲット言語
発行プログラム４１０は、図３に示したクラス・データ
構造体を含む言語束縛４１４を生成する。機能ブロック
４２０に示される言語コンパイラに制御が移り、この言
語コンパイラは、言語アプリケーション４１６とＳＯＭ
束縛４１２から追加の入力を受け取る。この言語コンパ
イラは、ユーザの好みに応じて、Ｃ言語、Ｆｏｒｔｒａ
ｎ、Ｃｏｂｏｌまたは他のコンパイラとすることができ
る。言語コンパイラからの出力は、後で実行するためＳ
ＯＭ実行時ライブラリと連係編集することのできるオブ
ジェクト・ファイル４２２である。

【０１７４】図５は、本発明によるＳＯＭオブジェクト
を使用するアプリケーションのリンク、ロードおよび実
行を示す流れ図である。末端ブロック５００から開始
し、直ちに機能ブロック５３０に移って、図４の符号４
２２で作成されたＳＯＭオブジェクト５１０と、ＳＯＭ
実行時ライブラリ５２０の動的リンクおよびロードを行
う。その後、機能ブロック５４０で、アプリケーション
が開始される。このアプリケーションは、図６、７、
８、９および１０に詳細に示すように、機能ブロック５
５０で、必要なクラスとオブジェクトの作成を呼び出
す。最後に、機能ブロック５６０で、このアプリケーシ
ョンを実行し、末端ブロック５７０で終了する。

【０１７５】 Ｍ．オブジェクト指向プログラムのバージョン独立性 本発明のこの態様は、全般的には、オブジェクト指向ア
プリケーションの改良に関し、具体的には、オブジェク
ト定義ライブラリとそれを使用するコンピュータ・アプ
リケーションとの独立した発展から生じる問題の解決に
関する。

【０１７６】バージョン独立の処理は、オブジェクト定
義ライブラリ（オブジェクト・クラス・ライブラリとも
称する）を使用する実行可能２進形式のコンピュータ・
アプリケーションを、ライブラリの使用期間中に当然発
生するオブジェクト定義の実装または仕様の変更から隔
離する。具体的に言うと、実行のたびにオブジェクト定
義を動的にロードするコンピュータ・アプリケーション
の未修正の実行可能２進形式によるオブジェクト定義の
使用を損なわずに、オブジェクト定義に対して以下の変
更を加えることが可能である。 １）オブジェクト定義に新規メソッドを追加する。 ２）あるメソッドの定義の位置を、子クラスからその親
クラスに移動する。 ３）あるオブジェクト定義に関連する私用インスタンス
・データの追加、削除または他の変更を行う。 ４）クラス階層に新規のクラス定義を挿入する。

【０１７７】この処理は、以下のような複数の技法を使
用する、プロセッサのメモリ内のアルゴリズムの動作に
よって達成される。メソッドおよびインスタンスのオフ
セットが、アプリケーションの２進イメージから削除さ
れる。Ｃ＋＋で定義されるモデルなどの静的オブジェク
ト・モデルでは、メソッド手続きテーブル内のオフセッ
ト（整数値）を使用して、各特定のメソッド名に対する
メソッド手続きが選択される。このオフセットは、その
メソッドが定義されているクラスのメソッドの数と順
序、ならびにその祖先クラスで定義されるメソッドの数
に依存する。

【０１７８】この手法は、非常に高速な形のメソッド解
決策(method resolution)であるという長所をもつ。し
かし、従来技術のオブジェクト・モデルでは、これらの
オフセットが、特定のオブジェクト・クラスを使用する
アプリケーションの２進イメージ中に置かれていたの
で、オフセットを変更する必要がある時、アプリケーシ
ョンを再コンパイルする必要があった。

【０１７９】ＳＯＭでは、メソッドに関連するオフセッ
トが、図３の議論で詳細に論じた、クラス・データ構造
体(class data structure)と称する各クラス用の単一の
メモリ・データ構造体に集められる。このデータ構造体
は、外部名を与えられ、その内容がアプリケーション内
で参照される。各クラス・データ構造体は、図１０に詳
細に示すように、クラス・オブジェクトが初期設定され
る時に、適切なオフセット値を含むように初期設定され
る。したがって、アプリケーションを実行するたびに、
すべてのオフセット値が、そのアプリケーションによっ
て使用されるクラスの現在の定義に基づいて再計算され
る。

【０１８０】クラス・データ構造体に記憶された値に対
する、１アプリケーションの２進イメージ内のどの参照
も、オフセットを含んでいることに留意されたい。しか
し、これらのオフセットは、上記に列挙した４種類の変
更を通じて一定に保つことができる。これは、クラス・
データ構造体が、特定のクラス内で定義されたメソッド
のオフセットだけを含んでおり、そのクラスが継承した
メソッドのオフセットを含んでいないからである。した
がって、あるクラスに追加された新規メソッドは、その
クラス内で既に定義されているメソッドのオフセット値
の位置を乱さずに、そのオフセットがクラス・データ構
造体の末尾に追加されることができる。

【０１８１】ＳＯＭのオブジェクト・インターフェース
定義言語（ＯＩＤＬ）は、上記の節「ＳＯＭのオブジェ
クト・モデル」で論じた解放順序(Release Order)部分
を含む。ＯＩＤＬの解放順序部分を用いると、クラスの
実装者は、新規メソッドのオフセット値が、あるクラス
で既に定義されているメソッドのメソッド・オフセット
値の後に追加されることを保証できるようになる。ま
た、ＯＩＤＬファイル内の解放順序部分は、図３で強調
されるように、あるクラスで定義されたメソッドのうち
の１つを親クラスに移動する場合に、クラス・データ構
造内に１エントリを保持させる。このエントリは、その
後、図１０に示すように、クラス・データ構造体を初期
設定する論理をＯＩＤＬコンパイラが追加する簡単な割
当て文によって、親のオフセット値から初期設定され
る。

【０１８２】同様な問題が、公用インスタンス・データ
に関して発生する。アプリケーションのオブジェクトの
状態データ構造体のうちの１つに含まれる公用インスタ
ンス変数にアクセスするアプリケーションは、そのオブ
ジェクトの状態データ構造体内のオフセットを介してそ
れを行わなければならない。従来技術では、このオフセ
ットが、アプリケーションの２進イメージに含まれてい
た。この技法を使用する場合には、そのオブジェクトの
祖先クラスの１つまたは複数のインスタンス・データ要
件のサイズが変化したか、あるいはそのオブジェクト自
体のインスタンス・データの配置が変化したためにオフ
セットが変化する時には必ず、そのアプリケーションの
２進イメージを（再コンパイルを介して）再生成しなけ
ればならない。

【０１８３】ＳＯＭでは、各公用データ変数のオフセッ
トを、図３と今後の議論で詳細に示すクラス・データ構
造体内に置くことによって、この問題を解決する。各ク
ラス・データ構造体は、図７および図１３に詳細に示す
ように、クラス・オブジェクトが初期設定される時に、
適切なオフセット値を含むように初期設定される。した
がって、アプリケーションを実行するたびに、すべての
オフセット値が、そのアプリケーションによって使用さ
れるクラスの現在の定義に基づいて再計算される。

【０１８４】Ｎ．アプリケーションの２進イメージから
のオブジェクト状態データ構造体のサイズの除去 オブジェクトの新規インスタンスを作成する時には、そ
のオブジェクトの状態データ構造体を保持するため、正
しい量のコンピュータ・メモリを割り振らなければなら
ない。従来技術では、このメモリ・ブロックのサイズ
が、アプリケーションの２進イメージに含まれていた。
この技法を使用する場合、オブジェクトの状態データ構
造体のサイズが変化するたびに、アプリケーションの２
進イメージを（再コンパイルを介して）再生成しなけれ
ばならない。ＳＯＭでは、この値が、そのオブジェクト
のクラス・オブジェクトに対する呼出しを介して入手可
能であり、したがって、これをアプリケーションの２進
イメージに含める必要はない。

【０１８５】上述の技法を用いると、アプリケーション
の２進イメージを再生成する必要なく、そのアプリケー
ションによって使用されるクラス定義に関して、前に強
調した４つの変更をそれぞれ発生させることができるよ
うになる。

【０１８６】図６は、本発明による新規ＳＯＭクラスの
生成を示す流れ図である。末端ブロック６００から開始
し、直ちに判断ブロック６１０の正しいバージョン番号
の試験に移って、そこで検査を行って、バージョン番号
の正しさを検証する。不正なバージョン番号が検出され
た場合、出力ブロック６１２でメッセージが表示され、
末端ブロック６１４で処理を打ち切る。正しいバージョ
ン番号が検出された場合は、判断ブロック６２０で別の
試験を行って、そのＳＯＭクラスが存在するか否かを判
定する。そのＳＯＭクラスが存在する場合、末端ブロッ
ク６２２で戻る。

【０１８７】判断ブロック６２０でＳＯＭクラスが存在
しない場合は、判断ブロック６３０で試験を行って、Ｓ
ＯＭ実行時環境が活動状態であるか否かを判定する。活
動状態でない場合は、機能ブロック６３２でＳＯＭ実行
時環境を呼び出す。ＳＯＭ環境が最初に存在していよう
といまいと、制御は判断ブロック６４０に移り、判断ブ
ロック６４０でＳＯＭ環境内にエラーがあるかどうか検
査が行われる。エラーが検出された場合は、出力ブロッ
ク６４２で適当なメッセージが提示され、末端ブロック
６４４で処理を打ち切る。エラーが検出されない場合
は、機能ブロック６５０に移り、そこで省略時のメタク
ラスを準備する。次に、機能ブロック６５２で、図７に
詳細に示すようにクラスを構築する。最後に、末端ブロ
ック６６０で戻る。

【０１８８】図７は、本発明による、新規なＳＯＭクラ
スの構築の詳細を示す流れ図である。末端ブロック７０
０から開始し、直ちに機能ブロック７１０に移り、そこ
で、図８に詳細に示すように総称クラス・オブジェクト
を作成する。次に、機能ブロック７２０で、この新規な
総称クラスを省略時値に初期設定する。この処理の詳細
は図９に示す。その後、機能ブロック７３０で、インス
タンス・データ・オフセットを、この特定の新規クラス
用に初期設定する。機能ブロック７４０に移り、そこ
で、図１０に示すように、この新規クラス用の各静的メ
ソッドを表す値を割り当てることによって、この新規ク
ラス用のクラス・データ構造体（図３）を初期設定す
る。

【０１８９】機能ブロック７５０で、親クラスをセット
し、機能ブロック７６０で、クラス・データを初期設定
し、機能ブロック７７０で、クラスを登録する。これら
のステップは、図２、１０および１３の議論で詳細に示
される新規クラス・データ構造体の更新を伴う。最後
に、末端ブロック７８０で戻る。

【０１９０】図８は、本発明による、新規なＳＯＭ総称
クラス・オブジェクトの構築の詳細を示す流れ図であ
る。末端ブロック８００から開始し、直ちに機能ブロッ
ク８１０に移り、そこでオブジェクト用にメモリを割り
振る。次に、判断ブロック８２０で試験を行って、メモ
リが割り振られたか否かを判定する。エラーが検出され
た場合は、出力ブロック８３０で適当なエラー・メッセ
ージが表示され、末端ブロック８４０で処理を打ち切
る。エラーが検出されない場合は、機能ブロック８５０
でそのオブジェクトの省略時値をセットし、末端ブロッ
ク８６０で戻る。

【０１９１】図９は、本発明による、新規ＳＯＭクラス
・オブジェクトの初期設定の詳細を示す流れ図である。
末端ブロック９００から開始し、直ちに判断ブロック９
１０に移り、試験を行って、新規ＳＯＭクラス・オブジ
ェクトの親クラスが存在するか否かを検出する。親クラ
スが存在する場合、機能ブロック９１２でその親クラス
を初期設定する。親クラスを初期設定した後、機能ブロ
ック９２０でクラス名用にメモリを割り振る。次に、判
断ブロック９３０で、再度試験を行って、新規ＳＯＭク
ラス・オブジェクトの親クラスが存在するか否かを検出
する。

【０１９２】親クラスが存在しない場合は、機能ブロッ
ク９３２で初期変数を０にセットし、機能ブロック９７
０に移る。親クラスが存在する場合は、機能ブロック９
４０、９５０および９６０で、その親クラスからの値に
基づいて、初期変数を更新する。その後、機能ブロック
９７０で、そのクラスのバージョン番号をセットし、判
断ブロック９８０で、エラー処理を実行する。エラーが
検出された場合、出力ブロック９８２で適当なメッセー
ジが表示され、末端ブロック９８４で処理を打ち切る。
エラーが検出されない場合は、末端ブロック９９０で戻
る。

【０１９３】図１０は、本発明による、オフセット値を
含むＳＯＭクラス・データ構造の初期設定の詳細を示す
図である。末端ブロック１０００から開始し、直ちに機
能ブロック１０１０に移り、次の静的メソッドの獲得か
らループが始まる。機能ブロック１０２０で、新規メソ
ッドの識別子をＳＯＭ実行時環境に登録する。次に、判
断ブロック１０３０で試験を行って、そのメソッドが親
クラスで既に登録されているか否かを判定する。そのメ
ソッドが登録されている場合、機能ブロック１０３２で
メソッド・オフセットをオーバーライドし、判断ブロッ
ク１０７０に移る。

【０１９４】そのメソッドがどの親クラスにも登録され
ていない場合、判断ブロック１０４０で試験を行って、
そのメソッドが現在のクラスで定義されているか否かを
判定する。そのメソッドが定義されている場合、機能ブ
ロック１０４２で既存のオフセットを使用し、判断ブロ
ック１０７０に移る。そのメソッドが定義されていない
場合は、機能ブロック１０５０でメモリを割り振り、機
能ブロック１０６０で値を初期設定する。機能ブロック
１０６０では、継承した静的メソッドの数を、そのクラ
スによってこれまでに処理された静的メソッドの数に加
えることによって、オフセットを計算する。判断ブロッ
ク１０７０で、エラー処理を行う。エラーが検出された
場合は、出力ブロック１０７２で適当なメッセージが表
示され、末端ブロック１０７４で処理を打ち切る。エラ
ー処理が完了した後に、判断ブロック１０８０で別の試
験を行って、処理する必要のある追加のメソッドがある
か否かを判定する。追加のメソッドがある場合には、機
能ブロック１０１０に移って、このループをもう一度繰
り返す。そうでない場合は、末端ブロック１０９０に移
って、そこで戻る。

【０１９５】Ｏ．親クラス・シャドウ化 オブジェクト指向プログラミングで親クラス・シャドウ
と称する、置換親クラスの動的挿入を実現するための論
理について、本明細書のこの節で詳細に論ずる。この処
理を行うと、特定のクラスに実行時にどの親クラスがリ
ンクされるかを示す静的にコンパイルされた定義を、実
行中に動的に変更できるようになる。静的にコンパイル
されたクラス階層に新規の親クラスが挿入できると、既
存のコードが２進形式になった後の、保守および機能強
化のための柔軟性が大きくなる。また、この結果は再コ
ンパイルなしで達成できるので、原資料にアクセスせず
にコードをカストマイズするための、新たな自由度が提
供される。

【０１９６】従来技術のシステムには、誘導クラスとそ
の親クラスの静的なリンクに関連する固有の制約があ
る。これらの制約には、誘導オブジェクトの状態データ
構造体のサイズを計算すること、誘導メソッドのメソッ
ド手続きテーブルを初期設定すること、および、誘導ク
ラスのメソッド中から親クラスのメソッドへのアクセス
を提供できないこと（親クラス解決策(parent class re
solution)と称する）が含まれる。

【０１９７】ＳＯＭオブジェクト・モデルは、実行時に
すべての親クラス情報を親クラス・オブジェクトを介し
て入手可能とすることによって、これらの静的参照を取
り除く。すなわち、誘導クラスの実装が、（親クラス解
決策をサポートするため）親クラスの状態データ構造の
サイズ、親クラスのメソッド手続きのアドレス、また
は、親クラスのメソッド手続きテーブルへのアクセスに
関する情報を必要とする時には、親クラス・オブジェク
トから情報を獲得するための適切な呼出しを置く。この
情報を得るための処理の詳細は、図７、８、９および１
０に示されている。

【０１９８】ＳＯＭは、すべてのＳＯＭプロセス用に１
つのクラス・マネジャを導入する。クラス・マネジャ
は、クラスの登録簿を保持する責任を負う。ＳＯＭコン
パイラによって生成されるクラス構築コードが、クラス
・マネジャと共働して、子クラス・オブジェクトの作成
時に、そのクラスとその親クラスの間の関係を確立す
る。ＳＯＭクラス・マネジャは、他のＳＯＭクラスと同
様にサブクラスに分けることのできるクラスのインスタ
ンスである。

【０１９９】誘導クラスは、ＳＯＭクラス・マネジャ・
オブジェクトに対する呼出しを行うことによって、その
親クラスへの接続を確立する。元のクラスの実装を代替
クラスの実装で置き換えたいと考えているアプリケーシ
ョン設計者は、次のステップに従う。

【０２００】１）SOMClassMgrのサブクラスを作って、
クラス名からクラス・オブジェクトを決定するための、
アプリケーション固有の新規の１組の規則を提供する
（すなわち、somClassFromId、somFindClassおよびsomF
indClsInFileの実装態様を変更する）。

【０２０１】これを行うための簡単で有用な方法は、既
存のクラス名の下にシャドウ・オブジェクトを登録する
メソッドを追加した後に、シャドウ化された名前を指定
するsomClassFromId、somFindClassまたはsomFindClsIn
Fileの後続のすべての呼出しで、呼出し元のアプリケー
ションにシャドウ・クラス・オブジェクトを返すことで
ある。

【０２０２】２）シャドウ化された親クラス・オブジェ
クトを有することになる誘導クラス・オブジェクトを作
成する前に、（上記のステップ１に記載したように）新
規のクラス・マネジャ・クラスのインスタンスを作成
し、これを既存のSOMClassMgrインスタンスから（メソ
ッドsomMergeIntoを介して）初期設定し、その後、ＳＯ
Ｍ実行時環境内に存在するSOMClassMgrインスタンスの
アドレスをオーバーライドすることによって、既存のSO
MClassMgrインスタンスを新規のクラス・マネジャ・イ
ンスタンスで置き換える。

【０２０３】３）やはりシャドウ化された親クラス・オ
ブジェクトを有することになる誘導クラス・オブジェク
トを作成する前に、アプリケーションで指定されるクラ
ス・マネジャ・オブジェクトの機能を使って、シャドウ
・クラス・オブジェクト（シャド化されたクラス・オブ
ジェクト）を登録する。

【０２０４】上記の３つのステップが完了した後に、誘
導クラスのオブジェクトを作成することができる。これ
らは、適当な親のシャドウ・クラス・オブジェクトにリ
ンクされる。これが有効に働くのは、図１１に示す、ク
ラス・オブジェクトを初期設定しその親クラス・オブジ
ェクトにリンクするのに特定の論理が使用されるからで
ある。この論理は、次の２つの基本ステップからなる。

【０２０５】１）まず、静的に既知の親クラス・オブジ
ェクトが作成されていることを確認するために、呼出し
を行う。これは、２つの重要な目的に役立つ。

【０２０６】（ａ）これによって、静的に既知の親クラ
ス定義の２進イメージに対する静的参照が作成され、し
たがって、親クラスの実装が、アプリケーションの２進
イメージにリンクされることが保証される。

【０２０７】（ｂ）これによって、次のステップが発生
する前に、少なくとも静的に既知の親クラス・オブジェ
クトが、ＳＯＭクラス・マネジャ・オブジェクトに登録
されていることが保証される。

【０２０８】静的に既知の親クラス・オブジェクトが
（たとえば、上述のシャドウ化ステップの後にアプリケ
ーションによって）既に作成されている場合、この時点
での２回目の試みは、無視される。

【０２０９】２）第２に、ＳＯＭクラス・マネジャ・オ
ブジェクトに対する呼出しを行って、誘導クラスの親ク
ラスの名前に基づいて、適当なクラス・オブジェクトの
アドレスを検索する。親クラスがシャドウ化されている
場合、この呼出しによって、シャドウ・クラス・オブジ
ェクトが返される。

【０２１０】上述の技法および機構を組み合わせると、
誘導クラスの２進イメージが親クラス・データを抽出す
るために誘導クラスが使用するクラス・オブジェクトの
正確なクラスに対する依存性から有効に隔離される。

【０２１１】子クラスとその親クラスの間に新規クラス
を挿入する際には、２つの制約に従わなければならな
い。第１に、その挿入は、子クラスのどのインスタンス
も作成しないうちに実装されなければならない。第２
に、挿入されたクラスも、元の親クラスの直接の子でな
ければならない。ＳＯＭクラス・マネジャは、実行時の
クラス間の関係を確立する時に仲介(intermediary)とし
て使用されるので、静的にリンクされたクラスであって
も、この方式でシャドウ化することができる。

【０２１２】図１１は、本発明による、静的に定義され
たクラス階層の親クラス・シャドウ化の詳細を示す図で
ある。末端ブロック１１００から開始し、直ちに機能ブ
ロック１１１０に移り、そこで、静的に定義された親ク
ラス・オブジェクトを作成する。次に、機能ブロック１
１２０でシャドウ親クラスを作成し、これを使用して、
静的に定義された親クラスをオーバーライドする。その
後、機能ブロック１１３０で子クラスを作成し、その子
クラスが、ＳＯＭクラス・マネジャに問い合わせて、静
的に定義された親クラスではなく、現在の親クラスを確
認する。末端ブロック１１４０で戻る。

【０２１３】Ｐ．再ディスパッチ・メソッド・スタブ オブジェクト指向プログラミングの中心的な態様を、メ
ソッド解決策(methodresolution)と称する。この処理で
は、オブジェクト、メソッドの識別子および引数がメソ
ッド呼出しに渡されると、特定のメソッドが選択され
る。Ｃ＋＋で使用されるモデルなど多くのオブジェクト
・モデルでは、メソッド解決策は、プログラムのソース
・コードの分析に基づいて、手続きの入口点であるオブ
ジェクト固有のテーブル内のオフセットを決定すること
からなる。このタイプの解決策(resolution)を、オブジ
ェクト・モデルでは静的と称する。Smalltalkで使用さ
れるモデルなどの他のオブジェクト・モデルでは、実行
時にオブジェクトの名前を使用して特定のメソッドを決
定することからなる、より動的なモデルが使用される。
オブジェクト・モデルでは、これを動的と称する。

【０２１４】本発明は、静的モデルと動的モデルの相違
を改善するための、再ディスパッチ・スタブと称するプ
ログラミング機構からなる。再ディスパッチ・スタブ
は、手続きの入口点のテーブル内に置くことのできる入
口点を有する、小さな手続きである。手続きの入口点の
テーブルは、静的オブジェクト・モデルにおいて、予想
される実際のメソッドの入口点の代用として使用され
る。再ディスパッチ・スタブは、動的オブジェクト・モ
デルの要件に基づいて自動的に生成される。再ディスパ
ッチ・スタブは、静的オブジェクト・モデルで生成され
た呼出しを動的オブジェクト・モデルに必要な形式に変
換し、その過程で不足する情報を供給する。したがっ
て、あるオブジェクトが、動的オブジェクト・モデルに
よって提供される静的オブジェクト・モデルからアクセ
スされる場合には、各入口点がそれぞれ特定の再ディス
パッチ・スタブを示す入口点のテーブルを介して、その
オブジェクトを静的オブジェクト・モデルに対して表現
することができる。

【０２１５】図１２は、本発明による再ディスパッチ・
メソッドを示す流れ図である。符号１２００は、特定の
オブジェクトの状態データ構造体である。最初のフルワ
ード１２１０が、そのオブジェクトのメソッド手続きテ
ーブル１２４０のアドレスを保持する。状態データ構造
体の残りの部分１２３０は、そのオブジェクトに属する
追加情報を保持する。メソッド手続きテーブル１２４０
は、特定のオブジェクト用の様々なメソッドのアドレス
を保持する。このオブジェクトと同一のクラスのすべて
のオブジェクトも、このメソッド手続きテーブル１２４
０を指すアドレスを保持する。これらのオブジェクトが
継承するどのメソッドも、メモリ内の、そのメソッドが
継承した元の先祖クラスのメソッド手続きテーブル１２
４０に現れるのと同じオフセットの所にメソッド手続き
アドレスを有する。

【０２１６】この図では、符号１２５０が、再ディスパ
ッチ・スタブ１２７０を指すポインタを保持する。再デ
ィスパッチ・スタブとは、クライアント・プログラムに
とって１つのメソッドにみえる命令の列である。ただ
し、この命令群は、符号１２６０に示されるように、メ
ソッド呼出しをあるオブジェクトの適切なディスパッチ
関数への呼出しに変換するにすぎない。符号１２６０に
あるアドレスは、そのオブジェクトのディスパッチ関数
１２８０を指すポインタである。すべてのＳＯＭオブジ
ェクトが、ディスパッチ関数を有する。ディスパッチ関
数１２８０は、再ディスパッチ・スタブから渡されたパ
ラメータに基づいて特定のメソッドを選択するアルゴリ
ズムを実装する。これらのパラメータには、そのメソッ
ドの識別子、識別されたメソッドに渡される１組の引数
を記述する文字列、およびその１組の引数を含むデータ
構造体が含まれる。

【０２１７】（i）オフセット値 図１３は、ＳＯＭクラス・データ構造体内の、単一の公
用(public)インスタンス変数用のオフセット値の初期設
定の詳細を示す流れ図である。この論理シーケンスは、
特定のクラス内で定義される各公用変数のそれぞれにつ
いて繰り返される（上記のＯＩＤＬの「データ部分」の
議論を参照されたい）。末端ブロック１３００から開始
し、直ちに機能ブロック１３１０に移る。機能ブロック
１３１０で、このクラスのオブジェクト状態データ内で
のインスタンス変数のオフセットを、図２の符号２３０
に示すオブジェクト状態データ構造体内でのこのクラス
のオブジェクト状態データの先頭部のオフセットに加え
ることによって、インスタンス変数のオフセットを計算
する。

【０２１８】そのクラスのオブジェクト状態データの先
頭部は、このクラスの先祖クラスの各オブジェクト状態
データそれぞれのサイズを足し合わせることによって決
定される。その後、機能ブロック１３２０に移り、その
時、計算されたオフセットが、ＯＩＤＬファイルのRele
ase Order部分における公用インスタンス変数名の位置
によって決定される、クラス・データ構造体内の位置に
記憶される（上記のＯＩＤＬの「解放順序部分」と図３
を参照されたい）。その後、末端ブロック１３３０に移
り、処理が完了する。

【０２１９】（ii）再ディスパッチ・スタブ 図１４は、再ディスパッチ・スタブを使用して静的メソ
ッド呼出しを動的メソッド呼出しに変換する時に発生す
る制御フローの詳細を示す流れ図である。末端ブロック
１４００から開始し、直ちに機能ブロック１４１０に移
る。機能ブロック１４１０で、そのクラスが定義された
時に決定された適切なクラス・データ構造体内の位置に
保持される、オブジェクトのメソッド手続きテーブル内
のオフセットの場所に記憶されたアドレスを取得するこ
とによって、再ディスパッチ・スタブのアドレスが、通
常の静的メソッド解決策の方式で決定される。

【０２２０】その後、機能ブロック１４２０に移り、再
ディスパッチ・スタブを、実際の静的メソッド手続きと
全く同様にして呼び出す。機能ブロック１４３０で、再
ディスパッチ・スタブが、オブジェクトのディスパッチ
・メソッドを（前述したように通常のメソッド解決策を
使用して）呼び出す。再ディスパッチ・スタブは、オブ
ジェクトのディスパッチ・メソッドに必要な当該メソッ
ドの識別子と記述子を呼出しに付加する。これらの値
は、再ディスパッチ関数定義がＳＯＭ ＯＩＤＬコンパ
イラによって生成される時に、組み込まれる。（注意：
上記のSOMObjectクラスの定義で詳細に述べたように、
すべてのクラスがディスパッチ・メソッドをサポートし
なければならない）。機能ブロック１４４０で、オブジ
ェクトのディスパッチ・メソッド手続きが、そのオブジ
ェクトのクラス固有のアルゴリズムを使用して、実際に
どのメソッド手続きを呼び出さなければならないのかを
決定する。

【０２２１】ＳＯＭは、オブジェクトのクラス・オブジ
ェクトに含まれるテーブル内でメソッドの識別子を表引
きして、メソッド手続きのアドレスを決定するようなア
ルゴリズムの、省略時実装態様を提供する。他のオブジ
ェクト・モデルでは、他のアルゴリズムを使用してもよ
い。その後、機能ブロック１４５０に移り、ブロック１
４４０で決定されたメソッド手続きを呼び出す。このメ
ソッド手続きが戻り値を返す時には、末端ブロック１４
６０で、それを再ディスパッチ・スタブの元の呼出し元
に返す。再ディスパッチ・スタブを用いると、オブジェ
クトを操作するアプリケーション・プログラムの変更を
必要とせずに、元の静的メソッド呼出しを任意の動的呼
出しの１つに変換できるようになる。

【０２２２】 （iii）メソッド手続きテーブルの初期設定 図１５は、そのクラスを使用するアプリケーションの実
行中に、メソッドに対するメソッド手続きの関連づけが
変更される可能性のあるクラス用にメソッド手続きテー
ブルを正しく初期設定する制御フローの詳細を示す流れ
図である。末端ブロック１５００から開始し、直ちに機
能ブロック１５１０に移り、メソッド手続きテーブル用
の空間を割り振る。そのクラスのオブジェクトのアドレ
ス用のエントリと、図７に従ってそのクラスによって定
義または継承される各メソッドとを保持するのに十分な
空間を割り振る。その後、機能ブロック１５２０に移
り、メソッド手続きテーブル内の各メソッド・エントリ
をその再ディスパッチ・スタブで置き換える。継承され
たメソッドの再ディスパッチ・スタブは、そのクラスの
親クラスに要求することによって決定される。そのクラ
ス用の再ディスパッチ・スタブは、ＳＯＭコンパイラに
よって生成され、そのクラスの各静的メソッドを登録す
る呼出し中に、クラス初期設定手続きに供給される。そ
の後、機能ブロック１５３０に移り、そのクラスのディ
スパッチ関数用のメソッド手続きテーブル・エントリ
を、そのクラスのディスパッチ関数の実際のアドレスで
置き換える（ディスパッチ関数スロット内に再ディスパ
ッチ・スタブのアドレスを有することは、それが無限ル
ープをもたらすはずなので、正しくない）。最後に、末
端ブロック１５４０に移り、処理が完了する。

【図面の簡単な説明】

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

【図２】本発明によるＳＯＭデータ構造を示す図であ
る。

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

【図４】本発明による言語中立なオブジェクト・インタ
ーフェースを示す流れ図である。

【図５】本発明によるＳＯＭオブジェクトを使用するア
プリケーションの、リンク、ロードおよび実行を示す流
れ図である。

【図６】本発明による新規なＳＯＭクラスの作成を示す
流れ図である。

【図７】本発明による、新規なＳＯＭクラスの構築の詳
細を示す流れ図である。

【図８】本発明による、新規なＳＯＭ総称クラス・オブ
ジェクトの構築の詳細を示す図である。

【図９】本発明による、新規なＳＯＭクラス・オブジェ
クトの初期設定の詳細を示す流れ図である。

【図１０】本発明による、オフセット値を含むＳＯＭク
ラス・データ構造の初期設定の詳細を示す図である。

【図１１】本発明による、静的に定義されたクラス階層
の親クラス・シャドウ化の詳細を示す図である。

【図１２】本発明による再ディスパッチ・メソッドを示
す流れ図である。

【図１３】本発明による、ＳＯＭクラス・データ構造内
の、単一の共用インスタンス変数用のオフセット値の初
期設定の詳細を示す流れ図である。

【図１４】本発明による、再ディスパッチ・スタブを使
用して静的メソッド呼出しを動的メソッド呼出しに変換
する時に発生する制御フローの詳細を示す流れ図であ
る。

【図１５】本発明による、１クラス用のメソッド手続き
テーブルを初期設定する制御フローの詳細を示す流れ図
である。

【符号の説明】

１０ 中央演算処理装置 １２ システム・バス １４ ランダム・アクセス・メモリ（ＲＡＭ） １６ 読取専用メモリ（ＲＯＭ） １８ 入出力アダプタ ２０ ディスク装置 ２２ ユーザ・インターフェース・アダプタ ２１０ 状態データ構造体 ２４０ メソッド手続きテーブル ２４８ クラス・オブジェクト・データ構造体 ４０４ ＳＯＭ ＯＩＤＬコンパイラ ４１０ ターゲット言語発行プログラム ４１２ ＳＯＭ束縛 ４１４ 言語束縛 ４１６ 言語アプリケーション ５１０ ＳＯＭオブジェクト ５２０ ＳＯＭ実行時ライブラリ １２００ 状態データ構造体 １２４０ メソッド手続きテーブル １２７０ 再ディスパッチ・スタブ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アンドリュー・リチャード・マーチン アメリカ合衆国78758、テキサス州オース チン、マーンズ・メドウ1070 534号 (72)発明者 ラリー・キース・レイパー アメリカ合衆国78750、テキサス州オース チン、レイクウッド・ドライブ 7860

Claims (6)

【特許請求の範囲】
1. 【請求項１】（ａ）クラス・オブジェクトを登録する手
   段と、（ｂ）クラス名に基づいて上記クラス・オブジェ
   クトを判定する手段と、（ｃ）再コンパイルを必要とせ
   ずに、上記クラス・オブジェクトで新規クラス・オブジ
   ェクトをシャドウ化する手段とを備える、静的にコンパ
   イルされたクラス階層内でクラスをシャドウ化するシス
   テム。
2. 【請求項２】登録される上記クラス・オブジェクトが、
   親クラス・オブジェクトである、請求項１に記載のシス
   テム。
3. 【請求項３】実行時に誘導クラス・オブジェクトとその
   親クラス・オブジェクトとの間の接続を確立する手段を
   含む、請求項１に記載のシステム。
4. 【請求項４】誘導クラス・オブジェクトの親クラス・オ
   ブジェクトをシャドウ化する手段を含む、請求項１に記
   載のシステム。
5. 【請求項５】シャドウ化能力を保持しながらアプリケー
   ションを親クラス・オブジェクトにリンクさせる手段を
   含む、請求項１に記載のシステム。
6. 【請求項６】（ａ）クラス・オブジェクトを登録するス
   テップと、（ｂ）クラス名に基づいて上記クラス・オブ
   ジェクトを判定決定するステップと、（ｃ）再コンパイ
   ルを必要とせずに、上記クラス・オブジェクトに関して
   新規クラス・オブジェクトをシャドウ化するステップと
   を含む、静的にコンパイルされたクラス階層内でクラス
   をシャドウ化する方法。