JPH0950370A - 高機能作成者クラス・パターン、マシン実行手続きおよびオブジェクト指向プログラミング・システム - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 オブジェクト指向プログラミング・システム
の既存のアプリケーション・コードを改訂せずに基本ク
ラスの新しいサブクラスをインスタンス化する。 【解決手段】 本高機能作成者設計パターンは、アプリ
ケーション・コードの残りの部分を修正せずに所定のア
プリケーション入力データの認識に応答して新しいアプ
リケーション・サブクラスをインスタンス化するため
に、既存のアプリケーションに追加された高機能作成者
サブクラスによって継承すべき基本クラスを指定する。
すべての高機能作成者サブクラスへの参照のリストを自
動的に更新するためのメソッドを含む動的リスト・オブ
ジェクトにより、アプリケーションから具体的な作成者
サブクラスに関する知識が必要なくなる。動的リスト・
オブジェクトは、アプリケーションに追加されたそれぞ
れの新しい作成者サブクラスの認識メソッドに応答して
自己更新するので、作成者サブクラスを追加するときに
更新する必要がない。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的には再使用
可能なメタクラス・タイプを作成するためのオブジェク
ト指向設計パターンに関し、より具体的にはオブジェク
ト指向アプリケーションにとって未知である、あるメタ
クラスの多相サブクラスをインスタンス化するための高
機能作成者クラスに関する。

【０００２】

【従来の技術】オブジェクト指向技術では、抽象化、カ
プセル化、モジュール性、階層、タイプ分け、並行性、
持続性という周知の原理を含む「オブジェクト・モデ
ル」を使用している。いずれの原理もそれ自体は新しい
ものではないが、すべての要素が相互依存的にまとまる
と、オブジェクト指向技術の基礎となる「オブジェクト
・モデル」を構成する。オブジェクト指向分析および設
計の基本的な扱い方については、Grady BoochによるObj
ect-Oriented Analysis and Design with Application
s, 2nd ed., The Benjamin/Cummings Publishing Co.,
Redwood City, CA, 1994を参照する。

【０００３】Boochの文献によると、「抽象化」とは、
あるオブジェクトの本質的な特徴であって、そのオブジ
ェクトを他のいかなる種類のオブジェクトからも区別す
るものであり、それにより、ビューア（viewer）の見通
しに対する明確に定義された概念境界を提供するものを
意味する。抽象化という特性は、カプセル化または情報
隠蔽により「再使用可能性」を伝えるものである。カプ
セル化とは、その構造体および挙動を構成する抽象化の
諸要素を区分するプロセスであり、すべての実現データ
構造およびメソッドをそのオブジェクトに対して秘密に
保ちながら、１組の属性および操作によりそれぞれの挙
動の指定を公に宣言することにより、抽象化とその実現
の契約上のインタフェースを分離する役割を果たす。オ
ブジェクト・タイプまたはクラスは、メソッドや手続き
がカプセル化されたデータ型およびエンティティ・タイ
プと同様のものである。データとメソッドはオブジェク
トによってカプセル化されて隠蔽され、このオブジェク
トは１つのクラスの具体的な「インスタンス」を構成す
る。「オブジェクト」と「インスタンス」という用語
は、当技術分野では交換して使用される。「階層」と
は、抽象化のランキングまたは順序付けである。「継
承」とは、クラス間の関係であり、１つのクラスが他の
１つまたは複数のクラスで定義された構造体または挙動
を共用する。サブクラスは、そのスーパークラスから属
性とメソッドを継承し、そのサブクラス専用の他の属性
とメソッドを追加したり、継承したものをオーバーライ
ドすることもできる。多くのオブジェクト指向プログラ
ミング言語では、「インスタンス」はそれぞれの「クラ
ス」の特性だけをすべて継承する。継承は、サブクラス
が１つまたは複数の汎用スーパークラスから継承するク
ラス間の「．．．は．．．の一種である」という「is-
a」関係階層を定義するもので、通常、サブクラスは、
既存の構造体および挙動を増加したり再定義することに
より、そのスーパークラスを特殊化する。「メタクラ
ス」とは、複数クラスからなる１つのクラスであり、そ
のインスタンス自体がクラスになっている。

【０００４】「抽象」クラスには「インスタンス」がま
ったくない。というのは、通常、その抽象操作を実現す
ることにより、その具体的なサブクラスがその構造体と
メソッドを増加すると予想して作成されるからである。
抽象操作は、抽象クラスによって宣言されるが、実現さ
れるわけではない。「基本クラス」は、クラス構造内で
最も汎用性の高いクラスであり、状況によってはすべて
のクラスの究極のスーパークラスを定義することができ
る。

【０００５】「タイプ分け」とは、タイプが異なるオブ
ジェクトの交換が行われないように、または非常に制限
的な交換のみが行われるように、あるオブジェクトのク
ラスを強制することである。オブジェクト「タイプ」
は、そのオブジェクトが所有可能な許容値の定義域と、
そのオブジェクトに対して実行可能な１組の操作とを定
義するものである。「クラス」と「タイプ」という用語
は、当技術分野では交換して使用されるが、完全に同義
ではない。オブジェクト指向システムは、タイプやクラ
スの合致が厳密に強制される「強いタイプ分け」または
合致の強制力が弱い「弱いタイプ分け」を含む場合があ
る。強いタイプ分けのシステムでは、基本クラス・イン
タフェースの小さい変更でもすべてのサブクラスの再コ
ンパイルを必要とするような、意味上の依存関係を取り
入れている。「静的バインド」と「動的バインド」とい
う関連概念は、名前がタイプまたはクラスにバインドさ
れる時期に関連する。静的バインドは、すべての変数お
よび式のタイプがコンパイル時に一定であることを意味
し、動的バインドは、すべての変数および式のタイプが
実行時まで未知であることを意味する。

【０００６】オブジェクトの「クラス」とその「タイ
プ」との区別は微妙であるが、重要である。オブジェク
トのクラスは、そのオブジェクトの実現方法を定義する
ものである。また、クラスは、そのオブジェクトの内部
状態と、その操作の実現を定義する。対照的に、オブジ
ェクトのタイプは、そのインタフェースのみに関連し、
そのインタフェースはそのオブジェクトが応答可能な１
組の要求である。１つのオブジェクトは多くのタイプを
持つことができ、クラスが異なる複数のオブジェクトは
同じタイプを持つことができる。クラスは、オブジェク
トが実行可能な操作を定義するものなので、オブジェク
トのタイプも定義する。１つのオブジェクトが１つのク
ラスの１つのインスタンスである場合、当技術分野で
は、そのオブジェクトがそのクラスによって定義された
インタフェースをサポートすることを意味する。

【０００７】「多相性」とは、単一の名前（変数宣言な
ど）が任意の共通スーパークラスによって関連付けられ
た多種多様なクラスのオブジェクトを示すことができる
というタイプ理論の一概念を表している。したがって、
この名前によって示されるオブジェクトは、任意の共通
する１組の操作に応答することができる。多相性は、継
承と動的バインドという特徴が相互作用する場合に存在
し、おそらく、オブジェクト指向プログラミング・シス
テムの最も強力な２つの特徴の１つである。

【０００８】十分構造化されたオブジェクト指向システ
ム・アーキテクチャはいずれもクラス設計用の標準パタ
ーンに基づいている。オブジェクト指向プログラミング
の分野で既知の重要な設計パターンについては、Erich
Gamma他による文献（DesignPatterns: Elements of Reu
sable Object-Oriented Software, Addison-WesleyPubl
ishing Co., Reading, MA, 1995）を参照する。Gamma他
の文献には、オブジェクト指向システムでの使用に適し
たクラス用の２３通りの設計パターンのカタログが記載
されている。

【０００９】Gamma他の文献によると、基本的に、クラ
ス継承とは、親クラスの機能性の再使用によってアプリ
ケーションの機能性を拡張するためのメカニズムであ
る。クラス継承により、古いオブジェクトに関して新し
い種類のオブジェクトを高速定義することができ、既存
のクラスに変更を加えるだけで新たな実現を行うことが
できる。また、クラス継承は、通常、１つの基本クラス
からの継承により、同一インタフェースを備えたオブジ
ェクト・ファミリーの定義を用意することによって多相
性をサポートする。継承を適切に使用する場合、１つの
基本クラスから派生するすべてのサブクラスがそのイン
タフェースを共用しなければならない。これは、サブク
ラスが操作を追加またはオーバーライドするだけであっ
て、親クラスの操作を隠蔽しないことを意味する。この
場合、すべてのサブクラスは、その基本クラス・インタ
フェースの要求に応答し、それらを基本クラスのすべて
のサブタイプにすることができる。

【００１０】当業者は、クラス継承にも何らかの欠点が
あることを認識している。第１に、継承はコンパイル時
に定義されるので、実行時に親クラスから継承した実現
を変更するための手段がまったくない。第２に、しかも
より重要なことに、親クラスはそのサブクラスの物理表
現の少なくとも一部を定義することが多い。この場合、
サブクラスの実現は親クラスの実現と非常に緊密な関係
になるので、親の実現を変更すると、強制的にサブクラ
スも変更しなければならない。このようにその親の実現
の詳細に対してサブクラスを公開すると、「カプセル化
遮断継承」になると当技術分野では言われている。

【００１１】すべてのオブジェクト指向プログラミング
・システムは、「カプセル化」と「継承」という２つの
重要な特徴間の緊張と対立を特徴とする。多相性を使用
することにより、読みやすさとプログラマの生産性が高
まるが、ソフトウェアの実現速度が低下する可能性もあ
る。したがって、当業者は、システム全体のパフォーマ
ンスを最適化するためにオブジェクト指向プログラミン
グ・システムの再使用性、拡張性、多相性という互いに
矛盾する特性のバランスを取るよう努力している。

【００１２】サブクラスの再使用を試みる場合、実現の
依存関係によって問題が発生する可能性がある。継承し
た実現のいずれかの態様が新しい問題の定義域に適さな
い場合、基本クラスを書き直すか、より適切なものに置
き換える必要がある。このような依存関係によって、柔
軟性が制限され、最終的には再使用性が制限される。こ
れに対する救済策の１つは、抽象クラスのみから継承す
ることである。というのは、通常、抽象クラスはほとん
どあるいはまったく実現を提供しないからである。クラ
ス継承よりオブジェクト合成を優先すると、それぞれの
クラスをカプセル化して単一タスクに集中させておくの
に役立つ。「委任」という概念は、再使用のために合成
を継承と同じ程度に強力なものにする方法を提供する。
委任により、２つのオブジェクトが要求の処理にかかわ
ることになる。すなわち、親クラスに要求をゆだねるサ
ブクラスのように、受信側オブジェクトはその「代行
者」に操作を委任する。委任は、既存のクラスを書き直
さずにコードの再使用性を確実にするためのメカニズム
として継承に取って代わるためのオブジェクト合成の使
い方の極端な例である。

【００１３】これほど極端ではないが、アプリケーショ
ンが抽象基本クラスによって確立されたプロトコルによ
り抽象基本クラスの様々なサブクラスを処理できるよう
にするために、抽象基本クラスから継承する複数組のオ
ブジェクトを含むようにアプリケーション・コードが作
成される場合も多い。このため、様々なサブクラスの詳
細に関する知識がないか、または複数のサブクラスの存
在に関する知識すらなくても、アプリケーションの大部
分を作成することができる。しかし、この戦略でも、実
際にサブクラスをインスタンス化するコードがアプリケ
ーション内のどこかに必ず存在していなければならない
という欠点がある。このようなコードを用意するには、
インスタンス化のために適切なサブクラスを選択できる
ようにするために、可能なすべてのサブクラスの知識が
必要である。したがって、アプリケーションに新しいク
ラスを追加すると、必ずシステム開発者は少なくともア
プリケーション・コードのこの部分を書き直して、シス
テムに追加するときにそれぞれの新しいサブクラスの知
識を取り入れなければならない。

【００１４】このように既存のクラス・コードの書き直
しが必要であるということは、新しいサブクラスを追加
するたびに、アプリケーション全体を再コンパイルしな
ければならないことを意味する。このような状況は当技
術分野では周知であるが、アプリケーションの柔軟性を
阻害するものであり、既存のアプリケーション・コード
を修正せずに所与の基本クラスの新しいアプリケーショ
ン・サブクラスを追加できるようにする何らかのメカニ
ズムの必要性が当技術分野で明確に認識されている。

【００１５】Gamma他の文献には、新しいサブクラスの
作成の影響からアプリケーションの大部分を分離するこ
とによってこの問題を制限しようと試みる設計パターン
がいくつか記載されているが、このような設計パターン
の最良のものは、アプリケーションのアーキテクチャ上
の主要要素を分離するだけであり、既存コードの変更を
すべて除去するわけではない。たとえば、前述のよう
に、インスタンス化に使用可能なサブクラスをリストす
るアプリケーション・コードは、サブクラスを追加した
ときに必ずプログラマが修正しなければならない。Gamm
a他による解決策はいずれも、アプリケーションにどの
新しいクラスが追加されたかをアプリケーションが把握
しなければならないという要件を除去することができな
い。このような周知の問題に対して使用可能な解決策が
ないため、当業者は、相変わらず、アプリケーションで
単一の新しいサブクラスを追加するためにアプリケーシ
ョン全体を再コンパイルせざるを得ない状態になってい
る。このような未解決の問題と欠点は当業者に明確に認
識されており、以下に記載するように本発明によって解
決される。

【００１６】

【発明が解決しようとする課題】本発明の一目的は、所
与のアプリケーション基本クラスの具体的なアプリケー
ション・サブクラスに関するすべての事前知識をアプリ
ケーションから除去するように機能する、新しい「高機
能作成者」設計パターンを提供することにある。アプリ
ケーションは具体的なサブクラスに関する知識を一切持
たないので、アプリケーションを修正せずにいつでも新
しいサブクラスを追加することができる。本発明の各高
機能作成者サブクラスは、所定の入力データの「認識」
に応答して新しいアプリケーション・サブクラスをイン
スタンス化できるようにするために、インスタンス化す
る必要があるアプリケーション・サブクラスの「認識」
に必要なメソッドを含む。本発明の利点は、認識された
入力データがユーザインタフェース・データを含むこと
ができるが、必ず含む必要はない点である。

【００１７】

【課題を解決するための手段】本発明の手続きは、アプ
リケーション基本クラスの各アプリケーション・サブク
ラスごとに作成者サブクラスをインスタンス化する抽象
クラス用の高機能設計者パターンを取り入れることによ
り、上記の問題を解決する。各「高機能」作成者サブク
ラスは、それがインスタンス化しなければならないアプ
リケーション・サブクラスを「認識する」ためのメソッ
ドを含む。このような認識メソッドは、アプリケーショ
ン・サブクラスを最初にインスタンス化する場合のみ必
要である。というのは、インスタンス化した後、各イン
スタンスはそれ専用のＩＤを維持し、それに応じて処理
できるからである。この「高機能」作成者基本クラス
は、既存のアプリケーション・コードの修正または再コ
ンパイルなしに新しいアプリケーション・サブクラスの
インスタンス化を可能にするため、作成者およびアプリ
ケーション・サブクラスのリストを更新するためのメソ
ッドを有する個別の「動的」リスト・オブジェクトと協
調する認識メソッドを有する。

【００１８】本発明をより完全に理解するため、ここ
で、添付図面に例示した実施例に関する以下の詳細な説
明を参照する。

【００１９】

【発明の実施の形態】本発明のプロセスは、アプリケー
ションでインスタンス化すべきそれぞれのアプリケーシ
ョン・サブクラスごとに使用する作成者クラスが、特定
の作成者クラスを使用してその指定のアプリケーション
・サブクラスのインスタンスを作成する必要があること
を「認識する」ためのメソッドを装備することができる
という予想外に有利な所見から生まれたものである。サ
ブクラス・インスタンスを作成する必要性を認識するた
めに使用するメソッド（複数も可）は、特定のアプリケ
ーションによる特異性が非常に強い場合があるので、２
つの例に関して以下に立証する。「認識メソッド」とと
もにこの「高機能」作成者クラスを使用すると、アプリ
ケーション基本クラスのインスタンスの作成してひとま
とめにする方法を隠すことができるので、アプリケーシ
ョン・システムは、一般に抽象アプリケーション基本ク
ラスによって定義されたオブジェクト・インタフェース
しか把握しない。高機能作成者クラスは、インスタンス
化すべきサブクラスを変化させるために継承を使用する
ので、新しいアプリケーション・サブクラスで実施され
た特定の実現詳細を備えた新しい作成者サブクラスを追
加するだけで、新しいアプリケーション・サブクラスを
そのアプリケーションに追加することができる。このよ
うな特定の詳細としては、新しいアプリケーション・サ
ブクラスを適切にインスタンス化するのに必要な抽象
「認識メソッド」に対する特定の変更内容を含む。

【００２０】本発明の高機能作成者基本クラスは、サブ
クラスをインスタンス化する特定の抽象アプリケーショ
ン・クラスとアプリケーション・コードが作成されたと
きに存在しなかった所与の抽象アプリケーション・クラ
スのサブクラスをインスタンス化するように機能する。
すなわち、既存のアプリケーション・コードを一切改訂
せずに、高機能作成者基本クラスから継承する新しい作
成者サブクラスをそのアプリケーションに追加するだけ
で、新しいアプリケーション・サブクラスをアプリケー
ションに追加することができる。

【００２１】アプリケーション・コードは、アプリケー
ションが抽象基本クラスで確立されたプロトコルにより
抽象基本クラスの様々なサブクラスを処理できるように
するために、抽象基本クラスのインスタンスである複数
組のオブジェクトを含むように作成される場合が多い。
このアーキテクチャにより、どのサブクラスをインスタ
ンス化すべきかだけをアプリケーションが把握すればい
いように、アプリケーションを作成することができる。
これまでは、このコードは潜在的サブクラスをすべて把
握しなければならなかったので、新しいサブクラスをア
プリケーション・システムに追加するたびに、開発者は
コードを書き直さざるを得なかった。本発明は、それぞ
れの新しい高機能作成者サブクラスをアプリケーション
に追加するたびにそれに応答してアプリケーション・サ
ブクラス・リストを更新するリスト保守メソッドを含む
「動的リスト・オブジェクト」をアプリケーションに追
加することにより、この問題を解決する。この動的リス
ト・オブジェクト・コードは「自己保守」型なので、新
しいアプリケーション・サブクラスを追加するときにコ
ードの修正が一切不要である。動的リスト・オブジェク
トは、その保守メソッドを呼び出して、内部のアプリケ
ーション・サブクラス・リストを更新する。これは、動
的リスト・オブジェクト・コードを修正せずにいくつで
も新しいサブクラスをアプリケーションに追加できるこ
とを意味する。既知の抽象作成者基本クラスからの修正
なしに作成者サブクラス・インタフェースが継承される
ので、新しい作成者サブクラスを追加するときに、上記
以外のアプリケーション・コードの変更が一切不要であ
る。これは、既存のアプリケーション・コードのどの部
分も修正せずにいくつでも新しいアプリケーション・サ
ブクラスを追加できることを意味する。

【００２２】このような利点および特徴は、アプリケー
ション例を参照すれば理解することができるので、次に
そのうちの２つについて説明する。図１は、上記のBooc
hの文献に定義された表記法を使用する、銀行用アプリ
ケーションの例のBoochクラス図である。BankingApplic
ation１０は、複数口座の異種リストを含むものと仮定
する。このアプリケーションは、「CheckingAccoun
t」、「SavingsAccount」、「IRAAccount」など、実際
にインスタンス化されていると思われる複数サブクラス
のAccountの詳細の把握を心配せずに銀行が多くの「Acc
ount」オブジェクトを含んでいることをアプリケーショ
ンが把握できるように作成されている。それぞれの具体
的なAccountサブクラス用のCreatorサブクラスは、それ
が作成する特定の口座サブクラスの特別な属性を表示す
るためのメソッドを含む。この場合、銀行側のユーザ
は、その指定タイプのオブジェクトをインスタンス化す
るように適切な作成者サブクラスに明示的に指示するこ
とにより、開設（インスタンス化）すべき新しい口座の
タイプを選択することができる。したがって、この例で
は、作成者サブクラスの選択要件をアプリケーションが
把握せずに、記述とフィードバックにより、ユーザ・イ
ンタフェースを介して「認識」が実施される。図１で
は、抽象高機能作成者基本クラスが「AccountCreator」
１２と命名されている。また、抽象アプリケーション基
本クラスは「Account」１４と命名されている。

【００２３】銀行用アプリケーション１０は、AccountC
reatorListクラス１６として図１に示す、AccountCreat
or１２の作成者サブクラスのリストを保守するための動
的リスト・オブジェクトも含む。AccountCreatorListク
ラス１６は、作成者の抽象基本クラス（AccountCreator
クラス１２）を保持するようにコーディングされている
ので、その作成者クラスを処理するコードを変更せずに
作成者リストに新しい作成者サブクラスを容易に追加す
ることができる。したがって、アプリケーション１０
は、何らかの入力を受け取ると、リスト内の各作成者と
照らし合わせてその入力をテストし、作成者の１つがそ
の入力を認識すると、適切なアプリケーション・サブク
ラスがインスタンス化される。アプリケーション１０
は、その入力が何であったか、どれだけ多様なタイプの
作成者がリスト上に存在するか、具体的などのタイプの
サブクラスをインスタンス化するかを把握する必要がな
い。アプリケーションは、それがオブジェクトのリスト
と作成者のリストを有していることと、新しい入力を処
理するために作成者のリストに移行する必要があること
だけ、把握すればよい。作成者のリストは、アプリケー
ションが所有し、インスタンス化可能な各サブクラスご
とに作成者を１つずつ含み、そのリストに新しい作成者
サブクラスを追加できるようにする保守メソッドを含
む。

【００２４】図１は、Boochの表記法を使用して、Banki
ngApplication１０がAccountCreatorList１６を「有
し」、そのリストがAccountCreator１２を「有する」こ
とを示している。また、BankingApplication１０は「Ac
countList」１８も有し、そのリストがAccountクラス１
４を有する。前述の動的リスト・オブジェクトは、Acco
untCreatorListインスタンス２０として図１に示されて
いる。リスト・インスタンス２０は、図１で使用する表
記法で示すように、インスタンス化によってクラス１６
とクラス１８の両方に関連付けられている。

【００２５】AccountCreator１２は、CheckingAccountC
reatorサブクラス２２およびSavingsAccountCreatorサ
ブクラス２４用の高機能作成者基本クラスである。サブ
クラス２２と２４はクラスであってオブジェクトではな
いので、図１には基本クラス１２のインスタンスとして
示されている。この基本クラスは、メタクラスでもよい
が、抽象クラスであることが好ましい。Boochによれ
ば、「メタクラス」とは、そのインスタンスそのものが
クラスになるようなクラスである。「抽象」クラスは、
通常、その抽象操作を実現することにより、その具体的
なサブクラスがその構造体とメソッドを増加すると予想
して作成される。メタクラスは、その実現が完全なもの
であり、したがって、インスタンスを持つことができる
が、そのインスタンスそのものがクラスになるようなク
ラスである。したがて、図１のAccountCreatorクラス１
２は、その具体的なサブクラス２２と２４が追加の実現
を増加するような抽象クラスである場合もあれば、その
インスタンス２２と２４そのものがクラスになるような
メタクラスである場合もある。いずれの戦略も本発明の
手続きを実施するために有用であるが、カプセル化の遮
断を回避するためには抽象基本クラスを使用する方が好
ましい。

【００２６】同様に、CheckingAccountサブクラス２６
とSavingsAccountサブクラス２８はAccountクラス１４
のアプリケーション・サブクラスであり、そのAccount
クラスはアプリケーション基本クラスであり、抽象また
は具体的なメタクラスのいずれでもよいが、抽象である
方が好ましい。

【００２７】CheckingAccountCreatorサブクラス２２
は、「実現のために」CheckingAccountサブクラス２６
を「使用して」アプリケーション・サブクラス・インス
タンスを作成する。サブクラス２２は、所与のサービス
を提供するために「供給者」サブクラス２６に依存する
「クライアント」である。この「実現」の依存関係は、
クライアント・クラス２２の操作が供給者クラス２６の
操作を呼び出すか、またはその戻りクラスまたは引数が
供給者クラス２６のインスタンスになるようなシグナチ
ャを有することを示している。したがって、作成者サブ
クラス２２はアプリケーション・サブクラス２６を呼び
出して、CheckingAccountというインスタンスを返す。
同様に、SavingsAccountCreator２４はSavingsAccount
２８を使用して、SavingsAccountをインスタンス化す
る。作成者サブクラス２４は、アプリケーション・サブ
クラス２８への「実現アクセス権」を有する。

【００２８】図２は、図１の銀行用アプリケーションの
例の論理図におけるオブジェクトの存在とそれらの関係
に関する操作例を示すBoochオブジェクト図である。図
３は、図２の操作例のBooch対話図を示している。

【００２９】図２〜３に示す操作例では、銀行側がクラ
イアント用の新しい当座預金口座の開設を希望している
と仮定する。まず、銀行側は、各口座タイプの名前と記
述を含む、アプリケーション内の様々な口座タイプのメ
ニューを検査する。このメニューそのものはアプリケー
ションによって生成され、アプリケーションは作成者サ
ブクラスのリストの走査に移行し、それぞれがその関連
アプリケーション・サブクラスの名前と記述を通知する
ように指示する。アプリケーションは、リスト上にいく
つ存在するか、またはリストされた要素に関する上記以
外のことを把握する必要がない。というのは、「Accoun
tCreator」基本クラス１２は、その抽象プロトコル内に
名前と記述を返すのに必要なメソッドを含むからであ
る。

【００３０】図２は、オブジェクト間で転送されるメッ
セージによってリンクされたオブジェクトの集合を示し
ている。たとえば、まず、ABankingAppオブジェクト３
０がAnAccountCreatorListオブジェクト３４にgetNex
t()メッセージ３２を送る。次に、リスト・オブジェク
ト３４がACheckingAccountCreatorオブジェクト３８にg
etAccountCreatorHandle()メッセージを送る。「ハンド
ル」を返した後、オブジェクト３０は作成者オブジェク
ト３８にgetAccountDescription()メッセージ４０を送
り、その作成者オブジェクトが適切な名前と記述をメニ
ューに返す。このプロセスは、「メニュー」がアセンブ
ルされるまでリスト３４内をループする。

【００３１】次に、銀行側は、オブジェクト３０への適
当なユーザ・インタフェース入力により、オブジェクト
３０にselectFromMenu()メッセージ４２を提供する。銀
行側が新しいクライアント用に「当座預金口座」を選択
すると仮定して、オブジェクト３０は次に作成者サブク
ラス３８にCreateAccount()メッセージ４４を送り、そ
れに対する応答として作成者サブクラス３８がACheckin
gAccountオブジェクト４６をインスタンス化し、メッセ
ージ４７によってそのデータをロードする。アプリケー
ション・オブジェクト３０は、add()メッセージ５０に
より、AnAccountListオブジェクト４８に新しい当座預
金口座４６を追加する。最後に、オブジェクト３０は、
作成者リスト・オブジェクト３４にACheckingAccountCr
eatorオブジェクト３８を追加するために、CreatorList
オブジェクト３４にadd()メッセージ５２を送る。ただ
し、図２〜３に示す例では、抽象口座作成者クラスに複
数の各種サブクラスの１つを例示するために当座預金口
座作成者クラスを使用していることに留意されたい。

【００３２】銀行側がその提供内容に「MoneyMarketAcc
ount」を追加すると決めた場合、MoneyMarketAccount用
の新しい作成者サブクラスを作成し、システムに追加す
ることができる。次に、新しい作成者を受け入れるアプ
リケーション・メソッドが実行され、（メッセージ５２
により）作成者リストに新しいMoneyMarketAccount作成
者が追加される。アプリケーションは抽象基本クラスAc
countCreator１２（図１）にしか関心がないので、Mone
yMarketAccount作成者クラスの実現詳細の知識を一切必
要としない。次に、アプリケーションはCreatorList３
４に移行し、口座記述メニューをアセンブルして表示す
ると、メニューに追加の記述が現れるが、既存のアプリ
ケーション・コードの改訂は行われない。

【００３３】図４は、本発明の手続きを使用する電子メ
ール処理アプリケーションの例のBoochクラス図を示し
ている。メールルーム・アプリケーション・オブジェク
ト５４は、着信メッセージを受信するためのメソッドを
含んでいる。アプリケーション５４は、着信メッセージ
を分解し、その要素を配布するためのメッセージ・クラ
ス５６を有する。Messageクラス５６はAddressListクラ
ス５８を有し、Mailroomアプリケーション５４はAddres
sCreatorListクラス６０を有する。Mailroomアプリケー
ション５４は、システム内で有効な多種多様なアドレス
をすべて処理しなければならない。メッセージがネット
ワークから到着すると、メッセージ内のアドレスを抽出
するためにメッセージ・テキストが分析され、これらの
アドレスがAddressCreatorクラス６６に渡される。次
に、着信メッセージで受信したアドレス形式を「認識」
しようと試みる際にクラス６６の複数の作成者サブクラ
スのそれぞれがそのメッセージを解析する。次に、認識
した作成者サブクラスが適切なアドレス・オブジェクト
をインスタンス化し、それにメッセージ・データをロー
ドし、それをメッセージのそのサブクラス用の正しいデ
ータ・メンバーに入れる。この例では、受信したメッセ
ージからのアドレス・テキストを解析することによって
「認識」が実施される。この電子メール・アプリケーシ
ョンの例と上記の銀行用アプリケーションの例との主な
違いは、適切な作成者サブクラスが必要なインスタンス
化を認識する方法にある。

【００３４】図４では、両方のリスト・クラス５８およ
び６０を参照して動的リスト・オブジェクト６２がイン
スタンス化される。リスト・クラス５８は抽象Address
基本クラス６４を有し、作成者リスト・クラス６０は抽
象AddressCreator基本クラス６６を有する。Address基
本クラス６４は、NoteAddressサブクラス６８およびOVA
ddressサブクラス７０によって例示される複数のアプリ
ケーション・サブクラスによって継承される。既存のア
プリケーション・コードを修正せずに新しい電子メール
・アドレス形式に対応するために、アドレス基本クラス
６４の新しいアプリケーション・サブクラスを追加する
ことができる。

【００３５】同様に、AddressCreator基本クラス６６
は、NoteAddressCreatorサブクラス７２およびOVAddres
sCreatorサブクラス７４によって例示される複数のサブ
クラスによって継承される高機能作成者クラスである。
サブクラス７２は、必要な実現詳細用のサブクラス６８
へのアクセス権を備えた新しいNoteAddressオブジェク
トをインスタンス化するように機能する。サブクラス７
４は、OVAddressオブジェクトをインスタンス化する際
にサブクラス７０への同様の実現アクセス権を有する。
Listオブジェクト６２は、サブクラス７２および７４に
よって例示されるすべての作成者サブクラスのリストを
含み、このリストを更新するのに必要なメソッドをクラ
ス６０から継承する。

【００３６】図５は、図４の電子メール・メールルーム
・アプリケーションの例の操作例用のBoochオブジェク
ト図を示している。図６は、図５の操作例用のBooch対
話図を示している。メールルーム・オブジェクト７６
は、電子メール・メッセージを受け取り、それをメッセ
ージ・オブジェクト７８に送る。Messageオブジェクト
７８は、そのメッセージを解析し、アドレス・リストを
抽出し、それをメッセージ８０に入れてanAddressList
オブジェクト８２に送る。次に、Mailroomオブジェクト
７６は、着信メッセージに対する応答としてアドレス・
オブジェクトのインスタンス化を要求するメッセージ８
４をanAddressCreatorListオブジェクト８６に送る。リ
スト・オブジェクト８６は、すべての作成者サブクラス
を段階的に通過し、アドレス・タイプの「認識」を尋ね
る認識（AddressText）メッセージ８８をそれぞれのサ
ブクラスに送る。図５の例には、NotesAddressCreator
オブジェクト９０とOVAddressCreatorオブジェクト９２
という２つの作成者オブジェクトの例が示されている。
複数の作成者オブジェクトの１つは、AddressTextメッ
セージ８８を認識すると、それに応答してただちに必要
なアドレス・オブジェクトをインスタンス化する。図５
では、OVAddress作成者オブジェクト９２がOVAddressと
してアドレス・テキストを認識し、OVAddress９４をイ
ンスタンス化し、OVAddressをメッセージ９５に入れて
新しいオブジェクト９４に送る。次に、Mailroomオブジ
ェクト７６がメッセージ・オブジェクト７８にhandleAn
otherAddress()メッセージ９６を渡し、次にそのオブジ
ェクトがAddressListオブジェクト８２にadd(Address)
メッセージ９８を送る。

【００３７】たとえばクラス８６から継承する「Intern
etAddress」作成者サブクラスをこのアプリケーション
に追加すると、この手続きに従って「InternetAddres
s」電子メール・メッセージが最初に到着したときにそ
れに対する応答としてリスト・オブジェクト８２が更新
される。このような到着により、図４のクラス６４から
継承する「InternetAddress」オブジェクトもインスタ
ンス化されるが、アプリケーション・コードは改訂され
ない。

【００３８】主に手続きとして本発明を説明している
が、当業者であれば、ＣＰＵ１０２と、ディスプレイ１
０４と、ユーザ・インタフェース（ＵＩ）１０６と、メ
モリ１０８および持続記憶装置１１０を含むデータ記憶
手段とを含む、図７に示す従来のデータ・プロセッサ１
００などの装置を本発明の方法の実施を容易にするよう
にプログラミングするか、またはその他の設計を施すこ
とも可能であることを理解できるだろう。データ処理シ
ステム１００は、メモリ１０８に格納されたプログラム
・オブジェクト１１２および１１４によって例示される
プログラム・オブジェクトなど、本発明の手続きを実行
するためのプログラム手段を含むことも可能である。ま
た、図８に示す事前記録済みフロッピー・ディスク１１
６などの製造物は、記憶媒体１１８と、本発明の方法の
実施を容易にするようにデータ処理システム１００に指
示するためにそれに記録されたプログラム手段とを含む
こともできる。このようなプログラム手段は、たとえ
ば、本発明の動的リスト・オブジェクトを実現するため
のプログラム手段１２０と、本発明の高機能作成者基本
クラス・メソッドを実現するためのプログラム手段１２
２とを含むことも可能である。当業者であれば、このよ
うな装置および製造物も本発明の精神および範囲内に該
当することを容易に理解できるだろう。

【００３９】当業者が上記の教示を考慮して本発明の他
の実施例および変更態様を容易に思いつくことは明らか
である。したがって、本発明の特許請求の範囲は、上記
の明細書および添付図面とともに考慮したときにこのよ
うな実施例および変更態様をすべて含むものとする。

【００４０】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００４１】（１）オブジェクト指向プログラミング・
システム（ＯＯＰＳ）アプリケーションで使用するため
の高機能作成者クラス・パターンであって、所定のアプ
リケーション入力を認識するためのメソッドと、前記入
力の認識に応答して前記ＯＯＰＳアプリケーションでア
プリケーション基本クラスのアプリケーション・サブク
ラスをインスタンス化するためのメソッドとを含むこと
を特徴とする、高機能作成者クラス・パターン。 （２）少なくとも１つのアプリケーション基本クラス
と、少なくとも１つの作成者基本クラスの１つまたは複
数の作成者サブクラスとを含む、オブジェクト指向プロ
グラミング・システム（ＯＯＰＳ）アプリケーションの
既存のアプリケーション・コードを改訂せずにアプリケ
ーション基本クラスの新しいアプリケーション・サブク
ラスをインスタンス化するためのマシン実行手続きであ
って、前記作成者サブクラスのそれぞれが所定のアプリ
ケーション入力を認識するためのメソッドと、前記アプ
リケーション基本クラスのアプリケーション・サブクラ
スをインスタンス化するためのメソッドとを有し、前記
マシン実行手続きが、（ａ）新しい前記所定のアプリケ
ーション入力を認識するためのメソッドと、前記新しい
アプリケーション・サブクラスをインスタンス化するた
めのメソッドとを有する新しい前記作成者サブクラスを
前記ＯＯＰＳアプリケーションに追加するステップと、
（ｂ）前記新しい作成者サブクラスへの参照を追加する
ためにリスト保守メソッドを実行することにより、前記
作成者サブクラスへの参照のリストを保守するためのメ
ソッドを有する動的リスト・オブジェクトを更新するス
テップと、（ｃ）前記ＯＯＰＳアプリケーション側でア
プリケーション入力を受け取るステップと、（ｄ）前記
新しい作成者サブクラスが受け取った前記アプリケーシ
ョン入力を前記新しい所定のアプリケーション入力と合
致するものとして認識するまで、前記作成者リスト・オ
ブジェクトで参照された前記作成者サブクラス内の前記
認識メソッドを実行するステップと、（ｅ）前記入力認
識に応答して前記新しいアプリケーション・サブクラス
のインスタンスを作成するために前記新しい作成者サブ
クラスのインスタンス化メソッドを実行するステップと
を含むことを特徴とする、マシン実行手続き。 （３）前記ＯＯＰＳアプリケーションが、ユーザからの
データを受け入れるためのユーザ・インタフェース手段
を含み、前記アプリケーション入力が、前記ユーザ・イ
ンタフェース手段から受け取ったユーザインタフェース
・データを含むことを特徴とする、上記（２）に記載の
マシン実行手続き。 （４）少なくとも１つのアプリケーションを有するオブ
ジェクト指向プログラミング・システム（ＯＯＰＳ）で
あって、アプリケーション基本クラスと、作成者基本ク
ラスの１つまたは複数の作成者サブクラスであって、前
記作成者サブクラスのそれぞれが所定のアプリケーショ
ン入力を認識するためのメソッドと、前記アプリケーシ
ョン基本クラスのアプリケーション・サブクラスをイン
スタンス化するためのメソッドとを有する１つまたは複
数の作成者サブクラスと、新しい前記所定のアプリケー
ション入力を認識するためのメソッドと、前記アプリケ
ーション基本クラスの新しい前記アプリケーション・サ
ブクラスをインスタンス化するためのメソッドとを有す
る新しい前記作成者サブクラスを前記リストに追加する
ためのメソッドを含む、前記作成者サブクラスへの参照
のリストを保守するためのメソッドを有する動的リスト
・オブジェクトとを含むことを特徴とする、オブジェク
ト指向プログラミング・システム。 （５）ユーザからのデータを受け入れるためのユーザ・
インタフェース手段をさらに含み、前記アプリケーショ
ン入力が、前記ユーザ・インタフェース手段から受け取
ったユーザインタフェース・データを含むことを特徴と
する、上記（４）に記載のオブジェクト指向プログラミ
ング・システム。 （６）少なくとも１つのアプリケーション基本クラス
と、少なくとも１つの作成者基本クラスの１つまたは複
数の作成者サブクラスとを含む、オブジェクト指向プロ
グラミング・システム（ＯＯＰＳ）アプリケーションを
含むコンピュータ・システムとともに使用するためのコ
ンピュータ・プログラム・プロダクトであって、前記作
成者サブクラスのそれぞれが所定のアプリケーション入
力を認識するためのメソッドと、前記アプリケーション
基本クラスのアプリケーション・サブクラスをインスタ
ンス化するためのメソッドとを有し、前記コンピュータ
・プログラム・プロダクトが、記録媒体と、前記記録媒
体上に記録された手段であって、新しい前記所定のアプ
リケーション入力を認識するためのメソッドと、前記新
しいアプリケーション・サブクラスをインスタンス化す
るためのメソッドとを有する新しい前記作成者サブクラ
スを前記ＯＯＰＳアプリケーションに追加するよう前記
コンピュータ・システムに指示するための手段と、前記
記録媒体上に記録された手段であって、前記新しい作成
者サブクラスへの参照を追加するためにリスト保守メソ
ッドを実行することにより、前記作成者サブクラスへの
参照のリストを保守するためのメソッドを有する動的リ
スト・オブジェクトを更新するよう前記コンピュータ・
システムに指示するための手段と、前記記録媒体上に記
録された手段であって、前記ＯＯＰＳアプリケーション
側でアプリケーション入力を受け取るよう前記コンピュ
ータ・システムに指示するための手段と、前記記録媒体
上に記録された手段であって、前記新しい作成者サブク
ラスが受け取った前記アプリケーション入力を前記新し
い所定のアプリケーション入力と合致するものとして認
識するまで、前記作成者リスト・オブジェクトで参照さ
れた前記作成者サブクラス内の前記認識メソッドを実行
するよう前記コンピュータ・システムに指示するための
手段と、前記記録媒体上に記録された手段であって、前
記入力認識に応答して前記新しいアプリケーション・サ
ブクラスのインスタンスを作成するために前記新しい作
成者サブクラスのインスタンス化メソッドを実行するよ
う前記コンピュータ・システムに指示するための手段と
を含み、それにより、既存のアプリケーション・コード
を改訂せずにアプリケーション基本クラスの新しいアプ
リケーション・サブクラスをインスタンス化することを
特徴とする、コンピュータ・プログラム・プロダクト。 （７）前記コンピュータ・システムが、ユーザからのデ
ータを受け入れるためのユーザ・インタフェース手段を
含み、前記アプリケーション入力が、前記ユーザ・イン
タフェース手段から受け取ったユーザインタフェース・
データを含むことを特徴とする、上記（６）に記載のコ
ンピュータ・プログラム・プロダクト。 （８）データ処理システムであって、データおよびプロ
グラム命令を格納するためのデータ記憶手段と、前記デ
ータ記憶手段に結合され、前記プログラム命令を実行す
るためのデータ・プロセッサ手段と、前記データ記憶手
段に格納されたオブジェクト指向プログラミング・シス
テム（ＯＯＰＳ）アプリケーションと、作成者サブクラ
スのそれぞれが所定のアプリケーション入力を認識する
ためのメソッドと、前記アプリケーション基本クラスの
アプリケーション・サブクラスをインスタンス化するた
めのメソッドとを有する、前記ＯＯＰＳアプリケーショ
ン内の少なくとも１つのアプリケーション基本クラスと
少なくとも１つの作成者基本クラスの１つまたは複数の
作成者サブクラスと、前記データ記憶手段内の拡張手段
であって、新しい前記所定のアプリケーション入力を認
識するためのメソッドと、前記新しいアプリケーション
・サブクラスをインスタンス化するためのメソッドとを
有する新しい前記作成者サブクラスを前記ＯＯＰＳアプ
リケーションに追加する拡張手段と、前記ＯＯＰＳアプ
リケーション内の動的リスト・オブジェクトであって、
前記リスト・オブジェクトが、前記新しい作成者サブク
ラスへの参照を追加するためにリスト保守メソッドを実
行することにより、前記作成者サブクラスへの参照のリ
ストを保守するためのメソッドを有する動的リスト・オ
ブジェクトと、前記データ・プロセッサ手段に結合され
た入力手段であって、前記ＯＯＰＳアプリケーション側
でアプリケーション入力を受け取るための入力手段と、
前記入力手段に結合された評価手段であって、前記新し
い作成者サブクラスが受け取った前記アプリケーション
入力を新しい所定の前記アプリケーション入力と合致す
るものとして認識するまで、前記作成者リスト・オブジ
ェクトで参照された前記作成者サブクラス内の前記認識
メソッドを実行するための評価手段と、前記評価手段に
結合されたランチャー手段であって、前記入力認識に応
答して前記新しいアプリケーション・サブクラスのイン
スタンスを作成するために前記新しい作成者サブクラス
のインスタンス化メソッドを実行するための前記ランチ
ャー手段とを含み、それにより、既存のアプリケーショ
ン・コードを改訂せずに前記アプリケーション基本クラ
スの新しいアプリケーション・サブクラスをインスタン
ス化することを特徴とする、データ処理システム。 （９）前記データ・プロセッサ手段に結合され、ユーザ
からのデータを受け入れるためのユーザ・インタフェー
ス手段をさらに含み、前記アプリケーション入力が、前
記ユーザ・インタフェース手段から受け取ったユーザイ
ンタフェース・データを含むことを特徴とする、上記
（８）に記載のデータ処理システム。 （１０）オブジェクト指向プログラミング・システム
（ＯＯＰＳ）アプリケーションでアプリケーション・サ
ブクラスを作成するためのシステムであって、所定のア
プリケーション入力を認識するための手段と、前記所定
のアプリケーション入力の認識に応答し、前記ＯＯＰＳ
アプリケーションでアプリケーション基本クラスのアプ
リケーション・サブクラスをインスタンス化するための
手段とを含み、それにより、既存のアプリケーション・
コードを改訂せずに前記アプリケーション基本クラスの
新しいアプリケーション・サブクラスをインスタンス化
することを特徴とする、システム。 （１１）前記ＯＯＰＳアプリケーションが、ユーザから
のデータを受け入れるためのユーザ・インタフェース手
段を含み、前記アプリケーション入力が、前記ユーザ・
インタフェース手段から受け取ったユーザ・インタフェ
ース・データを含むことをさらに特徴とする、上記（１
０）に記載のシステム。 （１２）オブジェクト指向プログラミング・システム
（ＯＯＰＳ）アプリケーションでアプリケーション・サ
ブクラスを作成するためのマシン実行手続きであって、
所定のアプリケーション入力を認識するステップと、前
記所定のアプリケーション入力の認識に応答し、前記Ｏ
ＯＰＳアプリケーションでアプリケーション基本クラス
のアプリケーション・サブクラスをインスタンス化する
ステップとを含み、それにより、既存のアプリケーショ
ン・コードを改訂せずにアプリケーション基本クラスの
新しいアプリケーション・サブクラスをインスタンス化
することを特徴とする、マシン実行手続き。 （１３）前記ＯＯＰＳアプリケーションが、ユーザから
のデータを受け入れるためのユーザ・インタフェース手
段を含み、前記アプリケーション入力が、前記ユーザ・
インタフェース手段から受け取ったユーザ・インタフェ
ース・データを含むことを特徴とする、上記（１２）に
記載のマシン実行手続き。 （１４）オブジェクト指向プログラミング・システム
（ＯＯＰＳ）アプリケーションとアプリケーション・サ
ブクラスとを含むコンピュータ・システムとともに使用
するためのコンピュータ・プログラム・プロダクトであ
って、前記コンピュータ・プログラム・プロダクトが、
記録媒体と、前記記録媒体上に記録された所定のアプリ
ケーション入力を認識するための手段と、前記記録媒体
上に記録された手段であって、前記所定のアプリケーシ
ョン入力の認識に応答し、前記ＯＯＰＳアプリケーショ
ンでアプリケーション基本クラスのアプリケーション・
サブクラスをインスタンス化するための手段とを含み、
それにより、既存のアプリケーション・コードを改訂せ
ずに前記アプリケーション基本クラスの新しいアプリケ
ーション・サブクラスをインスタンス化することを特徴
とする、コンピュータ・プログラム・プロダクト。 （１５）前記コンピュータ・システムが、ユーザからの
データを受け入れるためのユーザ・インタフェース手段
を含み、前記アプリケーション入力が、前記ユーザ・イ
ンタフェース手段から受け取ったユーザ・インタフェー
ス・データを含むことを特徴とする、上記（１４）に記
載のコンピュータ・プログラム・プロダクト。

【図面の簡単な説明】

【図１】本発明のプロセスを立証する銀行用アプリケー
ションの例のBoochクラス図である。

【図２】図１の銀行用アプリケーションの例のBoochオ
ブジェクト図である。

【図３】図１の銀行用アプリケーションの例のBooch対
話図である。

【図４】本発明のプロセスを立証する電子メール・アプ
リケーションの例のBoochクラス図である。

【図５】図４の電子メールの例のBoochオブジェクト図
である。

【図６】図４の電子メールの例のBooch対話図である。

【図７】本発明によるデータ処理システムの実施例の機
能ブロック図である。

【図８】本発明によるコンピュータ・プログラム・プロ
ダクトの実施例を示す図である。

【符号の説明】

１００ データ・プロセッサ １０２ ＣＰＵ １０４ ディスプレイ １０６ ユーザ・インタフェース（ＵＩ） １０８ メモリ １１０ 持続記憶装置 １１２ プログラム・オブジェクト １１４ プログラム・オブジェクト

Claims (15)

【特許請求の範囲】
1. 【請求項１】オブジェクト指向プログラミング・システ
   ム（ＯＯＰＳ）アプリケーションで使用するための高機
   能作成者クラス・パターンであって、 所定のアプリケーション入力を認識するためのメソッド
   と、 前記入力の認識に応答して前記ＯＯＰＳアプリケーショ
   ンでアプリケーション基本クラスのアプリケーション・
   サブクラスをインスタンス化するためのメソッドとを含
   むことを特徴とする、高機能作成者クラス・パターン。
2. 【請求項２】少なくとも１つのアプリケーション基本ク
   ラスと、少なくとも１つの作成者基本クラスの１つまた
   は複数の作成者サブクラスとを含む、オブジェクト指向
   プログラミング・システム（ＯＯＰＳ）アプリケーショ
   ンの既存のアプリケーション・コードを改訂せずにアプ
   リケーション基本クラスの新しいアプリケーション・サ
   ブクラスをインスタンス化するためのマシン実行手続き
   であって、前記作成者サブクラスのそれぞれが所定のア
   プリケーション入力を認識するためのメソッドと、前記
   アプリケーション基本クラスのアプリケーション・サブ
   クラスをインスタンス化するためのメソッドとを有し、
   前記マシン実行手続きが、 （ａ）新しい前記所定のアプリケーション入力を認識す
   るためのメソッドと、前記新しいアプリケーション・サ
   ブクラスをインスタンス化するためのメソッドとを有す
   る新しい前記作成者サブクラスを前記ＯＯＰＳアプリケ
   ーションに追加するステップと、 （ｂ）前記新しい作成者サブクラスへの参照を追加する
   ためにリスト保守メソッドを実行することにより、前記
   作成者サブクラスへの参照のリストを保守するためのメ
   ソッドを有する動的リスト・オブジェクトを更新するス
   テップと、 （ｃ）前記ＯＯＰＳアプリケーション側でアプリケーシ
   ョン入力を受け取るステップと、 （ｄ）前記新しい作成者サブクラスが受け取った前記ア
   プリケーション入力を前記新しい所定のアプリケーショ
   ン入力と合致するものとして認識するまで、前記作成者
   リスト・オブジェクトで参照された前記作成者サブクラ
   ス内の前記認識メソッドを実行するステップと、 （ｅ）前記入力認識に応答して前記新しいアプリケーシ
   ョン・サブクラスのインスタンスを作成するために前記
   新しい作成者サブクラスのインスタンス化メソッドを実
   行するステップとを含むことを特徴とする、マシン実行
   手続き。
3. 【請求項３】前記ＯＯＰＳアプリケーションが、ユーザ
   からのデータを受け入れるためのユーザ・インタフェー
   ス手段を含み、 前記アプリケーション入力が、前記ユーザ・インタフェ
   ース手段から受け取ったユーザインタフェース・データ
   を含むことを特徴とする、請求項２に記載のマシン実行
   手続き。
4. 【請求項４】少なくとも１つのアプリケーションを有す
   るオブジェクト指向プログラミング・システム（ＯＯＰ
   Ｓ）であって、 アプリケーション基本クラスと、 作成者基本クラスの１つまたは複数の作成者サブクラス
   であって、前記作成者サブクラスのそれぞれが所定のア
   プリケーション入力を認識するためのメソッドと、前記
   アプリケーション基本クラスのアプリケーション・サブ
   クラスをインスタンス化するためのメソッドとを有する
   １つまたは複数の作成者サブクラスと、 新しい前記所定のアプリケーション入力を認識するため
   のメソッドと、前記アプリケーション基本クラスの新し
   い前記アプリケーション・サブクラスをインスタンス化
   するためのメソッドとを有する新しい前記作成者サブク
   ラスを前記リストに追加するためのメソッドを含む、前
   記作成者サブクラスへの参照のリストを保守するための
   メソッドを有する動的リスト・オブジェクトとを含むこ
   とを特徴とする、オブジェクト指向プログラミング・シ
   ステム。
5. 【請求項５】ユーザからのデータを受け入れるためのユ
   ーザ・インタフェース手段をさらに含み、前記アプリケ
   ーション入力が、前記ユーザ・インタフェース手段から
   受け取ったユーザインタフェース・データを含むことを
   特徴とする、請求項４に記載のオブジェクト指向プログ
   ラミング・システム。
6. 【請求項６】少なくとも１つのアプリケーション基本ク
   ラスと、少なくとも１つの作成者基本クラスの１つまた
   は複数の作成者サブクラスとを含む、オブジェクト指向
   プログラミング・システム（ＯＯＰＳ）アプリケーショ
   ンを含むコンピュータ・システムとともに使用するため
   のコンピュータ・プログラム・プロダクトであって、前
   記作成者サブクラスのそれぞれが所定のアプリケーショ
   ン入力を認識するためのメソッドと、前記アプリケーシ
   ョン基本クラスのアプリケーション・サブクラスをイン
   スタンス化するためのメソッドとを有し、前記コンピュ
   ータ・プログラム・プロダクトが、 記録媒体と、 前記記録媒体上に記録された手段であって、新しい前記
   所定のアプリケーション入力を認識するためのメソッド
   と、前記新しいアプリケーション・サブクラスをインス
   タンス化するためのメソッドとを有する新しい前記作成
   者サブクラスを前記ＯＯＰＳアプリケーションに追加す
   るよう前記コンピュータ・システムに指示するための手
   段と、 前記記録媒体上に記録された手段であって、前記新しい
   作成者サブクラスへの参照を追加するためにリスト保守
   メソッドを実行することにより、前記作成者サブクラス
   への参照のリストを保守するためのメソッドを有する動
   的リスト・オブジェクトを更新するよう前記コンピュー
   タ・システムに指示するための手段と、 前記記録媒体上に記録された手段であって、前記ＯＯＰ
   Ｓアプリケーション側でアプリケーション入力を受け取
   るよう前記コンピュータ・システムに指示するための手
   段と、 前記記録媒体上に記録された手段であって、前記新しい
   作成者サブクラスが受け取った前記アプリケーション入
   力を前記新しい所定のアプリケーション入力と合致する
   ものとして認識するまで、前記作成者リスト・オブジェ
   クトで参照された前記作成者サブクラス内の前記認識メ
   ソッドを実行するよう前記コンピュータ・システムに指
   示するための手段と、 前記記録媒体上に記録された手段であって、前記入力認
   識に応答して前記新しいアプリケーション・サブクラス
   のインスタンスを作成するために前記新しい作成者サブ
   クラスのインスタンス化メソッドを実行するよう前記コ
   ンピュータ・システムに指示するための手段とを含み、
   それにより、既存のアプリケーション・コードを改訂せ
   ずにアプリケーション基本クラスの新しいアプリケーシ
   ョン・サブクラスをインスタンス化することを特徴とす
   る、コンピュータ・プログラム・プロダクト。
7. 【請求項７】前記コンピュータ・システムが、ユーザか
   らのデータを受け入れるためのユーザ・インタフェース
   手段を含み、 前記アプリケーション入力が、前記ユーザ・インタフェ
   ース手段から受け取ったユーザインタフェース・データ
   を含むことを特徴とする、請求項６に記載のコンピュー
   タ・プログラム・プロダクト。
8. 【請求項８】データ処理システムであって、 データおよびプログラム命令を格納するためのデータ記
   憶手段と、 前記データ記憶手段に結合され、前記プログラム命令を
   実行するためのデータ・プロセッサ手段と、 前記データ記憶手段に格納されたオブジェクト指向プロ
   グラミング・システム（ＯＯＰＳ）アプリケーション
   と、 作成者サブクラスのそれぞれが所定のアプリケーション
   入力を認識するためのメソッドと、前記アプリケーショ
   ン基本クラスのアプリケーション・サブクラスをインス
   タンス化するためのメソッドとを有する、前記ＯＯＰＳ
   アプリケーション内の少なくとも１つのアプリケーショ
   ン基本クラスと少なくとも１つの作成者基本クラスの１
   つまたは複数の作成者サブクラスと、 前記データ記憶手段内の拡張手段であって、新しい前記
   所定のアプリケーション入力を認識するためのメソッド
   と、前記新しいアプリケーション・サブクラスをインス
   タンス化するためのメソッドとを有する新しい前記作成
   者サブクラスを前記ＯＯＰＳアプリケーションに追加す
   る拡張手段と、 前記ＯＯＰＳアプリケーション内の動的リスト・オブジ
   ェクトであって、前記リスト・オブジェクトが、前記新
   しい作成者サブクラスへの参照を追加するためにリスト
   保守メソッドを実行することにより、前記作成者サブク
   ラスへの参照のリストを保守するためのメソッドを有す
   る動的リスト・オブジェクトと、 前記データ・プロセッサ手段に結合された入力手段であ
   って、前記ＯＯＰＳアプリケーション側でアプリケーシ
   ョン入力を受け取るための入力手段と、 前記入力手段に結合された評価手段であって、前記新し
   い作成者サブクラスが受け取った前記アプリケーション
   入力を新しい所定の前記アプリケーション入力と合致す
   るものとして認識するまで、前記作成者リスト・オブジ
   ェクトで参照された前記作成者サブクラス内の前記認識
   メソッドを実行するための評価手段と、 前記評価手段に結合されたランチャー手段であって、前
   記入力認識に応答して前記新しいアプリケーション・サ
   ブクラスのインスタンスを作成するために前記新しい作
   成者サブクラスのインスタンス化メソッドを実行するた
   めの前記ランチャー手段とを含み、それにより、既存の
   アプリケーション・コードを改訂せずに前記アプリケー
   ション基本クラスの新しいアプリケーション・サブクラ
   スをインスタンス化することを特徴とする、データ処理
   システム。
9. 【請求項９】前記データ・プロセッサ手段に結合され、
   ユーザからのデータを受け入れるためのユーザ・インタ
   フェース手段をさらに含み、前記アプリケーション入力
   が、前記ユーザ・インタフェース手段から受け取ったユ
   ーザインタフェース・データを含むことを特徴とする、
   請求項８に記載のデータ処理システム。
10. 【請求項１０】オブジェクト指向プログラミング・シス
    テム（ＯＯＰＳ）アプリケーションでアプリケーション
    ・サブクラスを作成するためのシステムであって、 所定のアプリケーション入力を認識するための手段と、 前記所定のアプリケーション入力の認識に応答し、前記
    ＯＯＰＳアプリケーションでアプリケーション基本クラ
    スのアプリケーション・サブクラスをインスタンス化す
    るための手段とを含み、それにより、既存のアプリケー
    ション・コードを改訂せずに前記アプリケーション基本
    クラスの新しいアプリケーション・サブクラスをインス
    タンス化することを特徴とする、システム。
11. 【請求項１１】前記ＯＯＰＳアプリケーションが、ユー
    ザからのデータを受け入れるためのユーザ・インタフェ
    ース手段を含み、 前記アプリケーション入力が、前記ユーザ・インタフェ
    ース手段から受け取ったユーザ・インタフェース・デー
    タを含むことをさらに特徴とする、請求項１０に記載の
    システム。
12. 【請求項１２】オブジェクト指向プログラミング・シス
    テム（ＯＯＰＳ）アプリケーションでアプリケーション
    ・サブクラスを作成するためのマシン実行手続きであっ
    て、 所定のアプリケーション入力を認識するステップと、 前記所定のアプリケーション入力の認識に応答し、前記
    ＯＯＰＳアプリケーションでアプリケーション基本クラ
    スのアプリケーション・サブクラスをインスタンス化す
    るステップとを含み、それにより、既存のアプリケーシ
    ョン・コードを改訂せずにアプリケーション基本クラス
    の新しいアプリケーション・サブクラスをインスタンス
    化することを特徴とする、マシン実行手続き。
13. 【請求項１３】前記ＯＯＰＳアプリケーションが、ユー
    ザからのデータを受け入れるためのユーザ・インタフェ
    ース手段を含み、 前記アプリケーション入力が、前記ユーザ・インタフェ
    ース手段から受け取ったユーザ・インタフェース・デー
    タを含むことを特徴とする、請求項１２に記載のマシン
    実行手続き。
14. 【請求項１４】オブジェクト指向プログラミング・シス
    テム（ＯＯＰＳ）アプリケーションとアプリケーション
    ・サブクラスとを含むコンピュータ・システムとともに
    使用するためのコンピュータ・プログラム・プロダクト
    であって、前記コンピュータ・プログラム・プロダクト
    が、 記録媒体と、 前記記録媒体上に記録された所定のアプリケーション入
    力を認識するための手段と、 前記記録媒体上に記録された手段であって、前記所定の
    アプリケーション入力の認識に応答し、前記ＯＯＰＳア
    プリケーションでアプリケーション基本クラスのアプリ
    ケーション・サブクラスをインスタンス化するための手
    段とを含み、それにより、既存のアプリケーション・コ
    ードを改訂せずに前記アプリケーション基本クラスの新
    しいアプリケーション・サブクラスをインスタンス化す
    ることを特徴とする、コンピュータ・プログラム・プロ
    ダクト。
15. 【請求項１５】前記コンピュータ・システムが、ユーザ
    からのデータを受け入れるためのユーザ・インタフェー
    ス手段を含み、 前記アプリケーション入力が、前記ユーザ・インタフェ
    ース手段から受け取ったユーザ・インタフェース・デー
    タを含むことを特徴とする、請求項１４に記載のコンピ
    ュータ・プログラム・プロダクト。