JP2003005968A

JP2003005968A - プログラム

Info

Publication number: JP2003005968A
Application number: JP2001183770A
Authority: JP
Inventors: Ryohei Iwamoto; 良平岩本
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2001-06-18
Filing date: 2001-06-18
Publication date: 2003-01-10

Abstract

(57)【要約】【課題】本発明は、継承によりインタフェースを変更あ
るいは追加することのできるプログラムに関し、呼出先
のクラスに変更が加えられた（呼出先のクラスを継承す
るクラスが作成された、あるいは呼出先のクラス自体に
修正が加えられた）ときに容易にインタフェース保証を
行なう。【解決手段】呼出先クラス生成のための「生成クラス」
を創設するとともに、呼出元クラスおよび呼出先クラス
の双方に、最上位の「抽象クラス」を創設する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、継承によりインタ
フェースを変更あるいは追加することのできるプログラ
ムに関する。

【０００２】

【従来の技術】近年、上記の継承という機能を有するオ
ブジェクト指向プログラミングによるプログラム開発が
盛んに行なわれている。

【０００３】ここで、プログラム開発で問題となるの
は、インタフェースの生成および呼出しを如何にして保
証するか、という点である。

【０００４】以下、インタフェースの生成および呼出し
の従来例について説明する。

【０００５】図１は、クラス定義から生成までの流れを
示す図である。ここでは、以下の手順で処理が行なわれ
る。

【０００６】（１）ソースコードにクラスを定義する。

【０００７】（２）ソースファイルをコンパイルし、オ
ブジェクトファイルを作成する。

【０００８】（３）オブジェクトファイルをリンクし、
実行可能なロードモジュールファイルを作成する。

【０００９】（４）実行可能なロードモジュールファイ
ルからメモリ上にロードする。

【００１０】（５）静的状態のクラスを生成し、動的状
態のアドレス（メモリ領域）を獲得する。

【００１１】（６）使用不要の際は生成時に獲得したア
ドレス（メモリ領域）を破棄する。

【００１２】この図１に示すように、メモリ上に展開さ
れている静的状態のクラスを動的状態にすることを、
「クラスを生成する」と称する。

【００１３】図２は、「具象クラスＡ’」と「具象クラ
スＢ’」の使用関係を示した図である。ここでは、後述
する本発明との対比上、クラスを具象クラスと称する。
ここでは、「具象クラスＡ’」は「具象クラスＢ’」を
使用する側であり、呼出し元のクラスである。また、
「具象クラスＢ’」は「具象クラスＡ’」から使用され
る側であり、呼出し先のクラスである。

【００１４】インタフェース呼出しまでの手順は以下の
とおりである。ここでは具象クラスＡ’が具象クラス
Ｂ’を生成して、その具象クラスＢ’のインタフェース
３を呼び出すときの例について説明する。

【００１５】（１）「具象クラスＡ’」は「具象クラス
Ｂ’」を‘生成して、「具象クラスＢ’」のアドレスを
獲得する。

【００１６】（２）「具象クラスＡ’」は「具象クラス
Ｂ’」のアドレスを指定して、インタフェース３のアド
レスを呼出す。

【００１７】（３）インタフェース３のインタフェース
情報テーブル部から、インタフェース３の実装部が呼出
される。

【００１８】（４）「具象クラスＡ’」は「具象クラス
Ｂ’」のアドレスを指定して、「具象クラスＢ’」のア
ドレスを破棄する。

【００１９】図３は、「具象クラスＡ’」と「具象クラ
スＢ’」の使用関係、および「具象クラスＢ’」と「具
象クラスＣ’」の使用関係を示した図である。

【００２０】ここで、「具象クラスＡ’」は「具象クラ
スＢ’」のインタフェース３のアドレスを呼出す使用関
係があり、「具象クラスＢ’」は「具象クラスＣ’」の
インタフェース５のアドレスを呼出す使用関係がある。
「具象クラスＣ’」のインタフェース４は“引数なし”
である。

【００２１】この場合、クラス間には、以下の依存関係
が存在する。

【００２２】（１）「具象クラスＢ’」のインタフェー
ス情報テーブル部内に「具象クラスＣ’」のインタフェ
ース情報テーブルがコンパイル時に取込まれている。ま
た「具象クラスＢ’」のインタフェース２は、引数に
「具象クラスＣ’」のアドレスが保持されている。

【００２３】（２）「具象クラスＡ’」のインタフェー
ス定義部内に「具象クラスＢ’」のインタフェース情報
テーブルがコンパイル時に取込まれている。したがっ
て、「具象クラスＡ’」のインタフェース定義部内に
も、上述の「具象クラスＢ’」のインタフェース情報テ
ーブルに含まれる「具象クラスＣ’」のインタフェース
情報テーブルが取込まれていることになる。

【００２４】

【発明が解決しようとする課題】次に、図２，図３を参
照して説明したプログラム構造における問題点を説明す
る。

【００２５】図４は、「具象クラスＡ”」と「具象クラ
スＢ”」の使用関係、および「具象クラスＢ’」と「具
象クラスＢ”」の継承関係を示した図である。

【００２６】ここでは、この図を参照しながら、図２を
参照して説明したプログラム構造の問題点について説明
する。

【００２７】ここで、「具象クラスＡ”」は「具象クラ
スＢ”」を使用する側であり、呼出し元のクラスであ
る。さらに、「具象クラスＡ”」は「具象クラスＡ’」
から継承した下位クラスである。また、「具象クラス
Ｂ”」は「具象クラスＡ”」から使用される側であり、
呼出し先のクラスである。さらに「具象クラスＢ”」は
「具象クラスＢ’」から継承した下位クラスである。

【００２８】この場合の、インタフェース呼出しの流れ
は以下のとおりである。

【００２９】（１）「具象クラスＡ”」は「具象クラス
Ｂ”」を生成して、「具象クラスＢ”」のアドレスを獲
得する。

【００３０】（２）「具象クラスＡ”」は「具象クラス
Ｂ”」のアドレスを指定して、インタフェース３のアド
レスを呼出す。

【００３１】（３）インタフェース３のインタフェース
情報テーブル部から、インタフェース３の実装部が呼出
される。

【００３２】（４）「具象クラスＡ”」は「具象クラス
Ｂ”」のアドレスを指定して、「具象クラスＢ”」のア
ドレスが破棄される。

【００３３】このインタフェース呼出しの流れから明ら
かなように、生成する対象クラスを「具象クラスＢ’」
から「具象クラスＢ”」に変更するとき、呼出し元の
「具象クラスＡ’」をそのまま再利用することは出来
ず、具象クラスＡ’のソースコード修正して具象クラス
Ａ’について再コンパイルを行なうか、もしくは「具象
クラスＡ’」から継承した「具象クラスＡ”」を新規に
作成する必要がある。

【００３４】呼出先の具象クラス（ここでは具象クラス
Ｂ’）に変更を加えた（ここでは具象クラスＢ’を継承
する具象クラスＢ”を作成した）ときに、変更が加えら
れた呼出先のクラスのみでなく、呼出元のクラス（ここ
では具象クラスＡ’）にも変更を加える（具象クラス
Ａ’のソースコードを修正するか、あるいは具象クラス
Ａ’を継承した具象クラスＡ”を作成する）必要を生じ
る結果となる。ここでは、２つのクラス間の例で示した
が、このことは、インタフェースの呼出しを保証するた
めには、バージョンアップされたクラス（ここでは具象
クラスＢ’を継承した具象クラスＢ”）を新たにコンピ
ュータにインストールするだけでは足りずに、多数のク
ラスの呼出元と呼出先の関係を全て調べてそのバージョ
ンアップされたクラスを呼び出す側のクラスまで全てを
修正し直す必要があることを意味し、プログラム開発に
多大な余計なエネルギーが費やされる結果を招くことに
なる。

【００３５】図５は、図３に示すプログラム構成におい
て、具象クラスＣ’のインタフェースが変更された場合
の影響範囲を示す図である。ここでは、具象クラスＣ’
のインタフェース４の引数を‘引数無し’から‘入出力
データ’に変更した場合について説明する。この場合、
以下に説明するように、具象クラスＣ’のインタフェー
ス変更により、その具象クラスＣ’を生成する具象クラ
スＢ’が影響を受けるだけではなく、具象クラスＢ’を
生成する具象クラスＡ’も具象クラスＢ’を介して間接
的に影響を受けることになる。すなわち、（１）「具象クラスＣ’」のインタフェース情報テーブ
ル部内にあるインタフェース４の引数に“入出力デー
タ”のアドレスが追加されることにより、「具象クラス
Ｃ’」のインタフェース情報テーブルが変更される。

【００３６】（２）「具象クラスＣ’」のインタフェー
ス変更により「具象クラスＢ’」のインタフェース情報
テーブル部内に取込まれた「具象クラスＣ’」のインタ
フェース情報テーブルと、変更された「具象クラス
Ｃ’」のインタフェース情報テーーブルの内容が不一致
となるため、「具象クラスＢ’」を再コンパイルし、
「具象クラスＢ’」のインタフェース情報テーブルを変
更する必要がある。

【００３７】（３）また、「具象クラスＢ’」を再コン
パイルすると、「具象クラスＡ’」のインタフェース定
義部内に取込まれた「具象クラスＢ’」のインタフェー
ス情報テーブルと、変更された「具象クラスＢ’」のイ
ンタフェース情報テーブルの内容が不一致となるため、
具象クラスＡ’についても再コンパイルが必要となる。

【００３８】すなわち、「具象クラスＣ’」のインタフ
ェースを変更したとき、「具象クラスＣ’」と使用関係
にある「具象クラスＢ’」についてインタフェース情報
テーブルの内容不一致を解決するために再コンパイルが
必要であるのみでなく、直接的には「具象クラスＣ’」
と使用関係のない「具象クラスＡ’」についても、イン
タフェース定義部内に取込まれた「具象クラスＢ’」の
インタフェース情報テーブルの内容が不一致となるため
「具象クラスＡ’」の再コンパイルが必要となる。

【００３９】このことは、直接的な使用関係（図５に示
す１次影響範囲）のみを調べてもインタフェースの呼出
しが保証されないこととなり、間接的な使用関係（図５
の２次影響範囲）まで全て調べ上げてその２次影響範囲
内のクラス全てについて再コンパイルを行なう必要を生
じ、この点も、プログラム開発に多大な負担を強いるこ
ととなり、プログラム開発の効率を大きく低下させる原
因となっている。

【００４０】本発明は、上記事情に鑑み、呼出先のクラ
スに変更が加えられた（呼出先のクラスを継承するクラ
スが生成された、あるいは呼出先のクラス自体に修正が
加えられた）ときに容易にインタフェース保証を行なう
ことのできる構造を持ったプログラムを提供することを
目的とする。

【００４１】

【課題を解決するための手段】上記目的を達成する本発
明のプログラムのうちの第１のプログラムは、１つもし
くは継承関係を伴う複数のクラスからなる呼出元機能
と、１つもしくは継承関係を伴う複数のクラスからなる
呼出先機能と、呼出元機能から呼び出されて呼出先機能
を生成する生成クラスとを有することを特徴とする。

【００４２】本発明の第１のプログラムは、呼出元機能
と呼出先機能の他に生成クラスを創設したため、図４を
参照して説明した、呼出先機能に継承クラス（図４に示
す具象クラスＢ”）が作成された場合に、呼出元機能
（図４に示す具象クラスＡ”）は何ら修正や再コンパイ
ルを行なうことなく、新たに作成されたクラス（図４に
示す具象クラスＢ”）をコンパイルするほかは、生成ク
ラスを修正して再コンパイルするだけでインタフェース
が保証される。

【００４３】また、上記目的を達成する本発明のプログ
ラムのうちの第２のプログラムは、インタフェースを持
たない、継承関係の最上位に位置する抽象クラスと、そ
の抽象クラスの下位に位置する１つ以上の具象クラスと
からなる呼出元機能と、呼出元機能から呼び出されて生
成される、インタフェースを持たない、継承関係の最上
位に位置する抽象クラスと、その抽象クラスの下位に位
置する１つ以上の具象クラスとからなる呼出先機能とを
有することを特徴とする。

【００４４】本発明の第２のプログラムは、従来（図５
参照）における具象クラスと同様の具象クラスを持つと
ともに、その具象クラスの上位にインタフェースを持た
ない抽象クラスを配置したため、呼出元クラス（図５に
示す具象クラスＣ’）を修正したときに再コンパイルす
る必要のあるのは、図５を参照して説明した１次影響範
囲内のみで済み、狭い範囲内のみの再コンパイルでイン
タフェースが保証される。

【００４５】さらに、上記目的を達成する本発明のプロ
グラムのうちの第３のプログラムは、インタフェースを
持たない、継承関係の最上位に位置する抽象クラスと、
その抽象クラスの下位に位置する１つ以上の具象クラス
とからなる呼出元機能と、インタフェースを持たない、
継承関係の最上位に位置する抽象クラスと、その抽象ク
ラスの下位に位置する１つ以上の具象クラスとからなる
呼出先機能と、呼出元機能から呼び出されて呼出先機能
を生成する生成クラスとを有することを特徴とする。

【００４６】本発明の第３のプログラムは、本発明の第
１のプログラムと本発明の第２のプログラムとの双方の
特徴を有するものであり、プログラムの開発、修正が大
幅に効率化される。

【００４７】

【発明の実施の形態】以下、本発明の実施形態について
説明する。

【００４８】図６は、本発明の一実施形態としてのプロ
グラムが実行される環境の１つを提供するコンピュータ
の外観斜視図である。

【００４９】このコンピュータ１００は、外観構成上、
本体装置１０１、その本体装置１０１からの指示に応じ
て表示画面１０２ａ上に画像を表示する画像表示装置１
０２、本体装置１０１に、キー操作に応じた各種の情報
を入力するキーボード１０３、表示画面１０２ａ上の任
意の位置を指定することにより、その位置に表示されて
いる例えばアイコン等に応じた指示を入力するマウス１
０４、および表示画面１０２ａ上に表示された画像をそ
のままプリントアウトするプリンタ１０５を備えてい
る。さらにこのコンピュータ１００は、通信ケーブル１
０６を有し、この通信ケーブル１０６やさらに図示しな
い通信回線を介して他のコンピュータやインターネット
等に接続されている。ここで、本体装置１０１は、外観
上、フレキシブルディスク（ＦＤ）を装填するためのＦ
Ｄ装填口１０１ａ、およびＣＤ−ＲＯＭを装填するため
のＣＤ−ＲＯＭ装填口１０１ｂを有する。

【００５０】図７は、図６に示す外観を有するコンピュ
ータ１００のハードウェア構成図である。

【００５１】このハードウェア構成図には、各種プログ
ラムを実行するＣＰＵ１１１、各種プログラムやデータ
等が保存されたハードディスク装置１１３、ハードディ
スク装置１１３に格納されたプログラムが読み出されＣ
ＰＵ１１１での実行のために展開される主メモリ１１
２、ＦＤ２００が装填され、その装填されたＦＤ２００
をアクセスするＦＤドライブ１１４、ＣＤ−ＲＯＭ３０
０が装填され、その装填されたＣＤ−ＲＯＭ３００をア
クセスするＣＤ−ＲＯＭドライブ１１５、プリンタ１０
５（図１参照）との間のデータ通信を担うプリンタイン
タフェース１１６、および通信ケーブル１０６および図
示しない通信回線を介在させて他のコンピュータやイン
ターネット等との間の通信を担うインタフェース１１７
が示されており、これらはバス１１０を介して相互に接
続されている。

【００５２】図８は、本発明の第１のプログラムの一実
施形態を示すプログラム構成図である。

【００５３】ここには、「具象クラスＡ’」と、「具象
クラスＢ’」および「具象クラスＢ”」との間の使用関
係、および、「具象クラスＢ’」と「具象クラスＢ”」
の継承関係が図示されている。

【００５４】ここでは、「具象クラスＡ’」は「具象ク
ラスＢ’」および「具象クラスＢ”」を使用する側であ
り、呼出し元のクラスである。一方、「具象クラス
Ｂ’」は「具象クラスＡ’」から使用される側であり、
呼出し先のクラスである。また、「具象クラスＢ”」も
「具象クラスＡ’」から使用される側であり、呼出し先
のクラスである。さらに「具象クラスＢ”」は「具象ク
ラスＢ’」から継承した下位クラスである。また、「生
成クラス」は生成インタフェースを用意し、当該クラス
（ここでは、具象クラスＢ’あるいは具象クラスＢ”）
を生成する機能を持つ。

【００５５】すなわち、「具象クラスＢ”」が未だ存在
しないときは、「生成クラス」には、「具象クラス
Ｂ’」が生成されるように記述されており、「具象クラ
スＢ”」が作成されたときは、「具象クラスＢ”」が生
成されるように「生成クラス」のソースコードが書き換
えられて再コンパイルされる。

【００５６】この図８のプログラム構成におけるインタ
フェース呼出しまでの流れは以下のとおりである。

【００５７】（１）「具象クラスＡ’」は「生成クラ
ス」の生成インタフェースを呼出し、「具象クラス
Ｂ’」または「具象クラスＢ”」の当該クラスのアドレ
スを獲得する。

【００５８】（２）「具象クラスＡ’」は「具象クラス
Ｂ’」または「具象クラスＢ”」のアドレスを指定し
て、インタフェース３のアドレスを呼出す。

【００５９】（３）「具象クラスＢ’」または「具象ク
ラスＢ”」のインタフェース３のインタフェース情報テ
ーブル部から、インタフェース３の実装部が呼出され
る。

【００６０】（４）「具象クラスＡ’」は「具象クラス
Ｂ’」または「具象クラスＢ”」のアドレスを指定し
て、「具象クラスＢ’」または「具象クラスＢ”」のア
ドレスが破棄される。

【００６１】このように、この図８のプログラム構成に
よれば、「具象クラスＢ’」がバージョンアップされて
呼出し先の対象が「具象クラスＢ”」に変更されても、
呼出し元の「具象クラスＡ’」はソースコードを変更す
る必要がなく、既存のクラスをそのまま容易に再利用す
ることが可能となる。また、クラスの生成に関するソー
スコードを生成クラス内に隠蔽することによりバージョ
ンアップに伴うソースコード修正をその生成クラスのみ
に局所化することができ、呼出元のクラスは汎化された
生成インタフェースを使用することにより将来的にイン
タフェース保証を受けることが可能となる。

【００６２】図９は、本発明の第２のプログラムの一実
施形態を示すプログラム構成図である。

【００６３】ここには、「抽象クラス」が導入されてお
り、この「抽象クラス」を導入したときの「具象クラス
Ｃ’」のインタフェース変更により受ける影響範囲が図
示されている。

【００６４】ここでは、各具象クラスの最上位に、それ
ぞれ「抽象クラスＡ」と「抽象クラスＢ」、および「抽
象クラスＣ」を作成する。これら抽象クラスはインタフ
ェースを持たない。この場合、「具象クラスＢ’」のイ
ンタフェース情報テーブル部内に「抽象クラスＣ」のイ
ンタフェース情報テーブル（抽象クラスはインタフェー
スを持たない）がコンパイル時に取込まれる。また、
「具象クラスＢ’」のインタフェース２の引数に「抽象
クラスＣ」のアドレスが保持される。さらに、「具象ク
ラスＢ’」のインタフェース定義部内に「具象クラス
Ｃ’」のインタフェース情報テーブルがコンパイル時に
取込まれ、インタフェース５のアドレス呼出しをする。

【００６５】ここで、図５に示す従来例の場合と同様、
「具象クラスＣ’」のインタフェース４の引数が“引数
無し”から“入出カデータ”にインタフェース変更され
たものとする。

【００６６】このインタフェース変更による他クラスへ
の影響内容は以下のとおりである。

【００６７】（１）「具象クラスＣ’」のインタフェー
ス情報テーブル部内にあるインタフェース４の引数に
“入出カデータ”のアドレスが追加され、「具象クラス
Ｃ’」のインタフェース情報テーブルが変更される。

【００６８】（２）この「具象クラスＣ’」のインタフ
ェース変更があっても、「具象クラスＢ’」のインタフ
ェース情報テーブル部内に取込まれた「抽象クラスＣ」
のインタフェース情報テーブル（抽象クラスはインタフ
ェースを持たない）は変更されることはないため、この
点にだけ着目すれば「具象クラスＢ’」の再コンパイル
は不要に見える。しかし、「具象クラスＢ’」のインタ
フェース定義部内に取込まれた「具象クラスＣ’」のイ
ンタフェース情報テーブルと、変更された「具象クラス
Ｃ’」のインタフェース情報テーブルの内容が不一致と
なるため「具象クラスＢ’」の再コンパイルが必要であ
る。尚、このとき「具象クラスＢ’」のインタフェース
情報テーブルが変更されることは無い。

【００６９】（３）「具象クラスＡ’」のインタフェー
ス定義部内に取込まれた「具象クラスＢ’」のインタフ
ェース情報テーブルについては変更されていないため、
「具象クラスＡ’」の再コンパイルは不要である。

【００７０】このように、図９のプログラム構成によれ
ば、継承関係にあるクラス単位の最上位に抽象クラスが
用意され、この抽象クラスはインタフェースを持たない
ため将来的にもインタフェース変更は発生しない。この
ため、この抽象クラスを２つのクラス間のインタフェー
スに使用することにより、将来に渡りインタフェースを
保証することが可能となる。再コンパイルの有無は、直
接関係する１次影響範囲の必要最小限に閉じられる。

【００７１】図１０は、本発明の第３のプログラムの一
実施形態を示すプログラム構成図である。この図１０に
は、図８に示す第１のプログラムの一実施形態と図９に
示す第２のプログラムの一実施形態とが組み合わされた
最終形態が図示されている。

【００７２】この最終形態では前述の抽象クラスに、継
承関係のあるクラス単位に役割を持たせた機能を表す普
遍的な一意な機能名が定義されている。この機能名を生
成インタフェース内で生成するクラスの識別に使用する
ことで、継承関係のクラス単位に当該クラスを生成する
ことが可能となる。また、生成に関するインタフェース
を一本化することができ、容易にインタフェースの保証
が可能となる。

【００７３】この図１０のインタフェース呼出しの流れ
は、図８，図９を参照して説明済であるため、重複説明
は省略する。

【００７４】

【発明の効果】以上、説明したように、本発明によれば
ソフトウェア部品の再利用を行なう際にクラスのインタ
フェースを将来に渡り保証することができ、開発の効率
化と生産性の向上、および保守のコスト低減に大きく寄
与する。

【００７５】すなわち、本発明の第１のプログラムによ
れば、ソースコードのプログラム修正が不要となり、容
易に再利用が可能となる。

【００７６】また、本発明の第２のプログラムによれ
ば、実行可能なオブジェクトコードの再コンパイルが不
要となり、混在するバージョン下でのシステム動作が可
能となる。

【図面の簡単な説明】

【図１】クラス定義から生成までの流れを示す図であ
る。

【図２】「具象クラスＡ’」と「具象クラスＢ’」の使
用関係を示した図である。

【図３】「具象クラスＡ’」と「具象クラスＢ’」の使
用関係、および「具象クラスＢ’」と「具象クラス
Ｃ’」の使用関係を示した図である。

【図４】「具象クラスＡ”」と「具象クラスＢ”」の使
用関係、および「具象クラスＢ’」と「具象クラス
Ｂ”」の継承関係を示した図である。

【図５】図３に示すプログラム構成において、具象クラ
スＣ’のインタフェースが変更された場合の影響範囲を
示す図である。

【図６】本発明の一実施形態としてのプログラムが実行
される環境の１つを提供するコンピュータの外観斜視図
である。

【図７】図６に示す外観を有するコンピュータのハード
ウェア構成図である。

【図８】本発明の第１のプログラムの一実施形態を示す
プログラム構成図である。

【図９】本発明の第２のプログラムの一実施形態を示す
プログラム構成図である。

【図１０】本発明の第３のプログラムの一実施形態を示
すプログラム構成図である。

【符号の説明】

１００コンピュータ１０１本体装置１０２画像表示装置１０３キーボード１０４マウス１０５プリンタ１１１ＣＰＵ１１２主メモリ１１３ハードディスク装置

Claims

【特許請求の範囲】

【請求項１】１つもしくは継承関係を伴う複数のクラ
スからなる呼出元機能と、１つもしくは継承関係を伴う複数のクラスからなる呼出
先機能と、前記呼出元機能から呼び出されて前記呼出先機能を生成
する生成クラスとを有することを特徴とするプログラ
ム。
【請求項２】インタフェースを持たない、継承関係の
最上位に位置する抽象クラスと、該抽象クラスの下位に
位置する１つ以上の具象クラスとからなる呼出元機能
と、該呼出元機能から呼び出されて生成される、インタフェ
ースを持たない、継承関係の最上位に位置する抽象クラ
スと、該抽象クラスの下位に位置する１つ以上の具象ク
ラスとからなる呼出先機能とを有することを特徴とする
プログラム。
【請求項３】インタフェースを持たない、継承関係の
最上位に位置する抽象クラスと、該抽象クラスの下位に
位置する１つ以上の具象クラスとからなる呼出元機能
と、インタフェースを持たない、継承関係の最上位に位置す
る抽象クラスと、該抽象クラスの下位に位置する１つ以
上の具象クラスとからなる呼出先機能と、前記呼出元機能から呼び出されて前記呼出先機能を生成
する生成クラスとを有することを特徴とするプログラ
ム。