JP5189986B2 - オブジェクト合成に対する拡張可能メカニズム - Google Patents

Description

この発明は、オブジェクト合成に対する拡張可能メカニズムに関する。

コンピューティング技術の進歩によりコンピュータは、基本的な数学的計算に利用可能な高コストで低機能性の装置から、ワードプロセッシング、友人間および家族間の即時通信、支払い、エンターテイメント、等に利用可能な低コストで高機能性の装置へと変化することができた。この機能性における急激な変化を相対的に短期間で可能とするため、トランジスタのサイズが大幅に縮小され、それにより（単一の集積回路上に配置可能な相当数のトランジスタのため）集積回路に大量のメモリ、高速な処理速度を与えることが可能となった。これらの進歩により、コンピュータプログラマが使用してアプリケーションを生成および／または既存アプリケーションを改善するための、より堅牢で柔軟なプログラミング環境が作成された。より詳細には、今日では複数のプログラミング言語が存在し、プログラマは選択した言語に関連する熟知度および／または機能性に基づいて特定の言語を選択することができる。

より詳細には、プログラミング言語は、特に命令をコンピュータまたはマイクロプロセッサに伝達してタスクを実行するために使用される形式言語である。長年の間、オブジェクト指向プログラミングが、設計者およびプログラマがコンピュータシステム内部の機能性の実装に利用する多数の良く知られた有名なモデルの１つとなっている。オブジェクト指向プログラミングは、他のプログラミング言語と比べて独特である。なぜならば、オブジェクト指向プログラミングは他のモデルのようにアクションではなく、オブジェクトまたは物の観点からプログラミングを見ることを前提とするからである。

オブジェクト技術の利点は３つの基本的原理、即ちカプセル化、多相性および継承から生じる。オブジェクトは、そのデータおよび関連方法の内部構造を隠蔽またはカプセル化する。実装の詳細を公開する代わりに、オブジェクトはインタフェースを提示し、余分な情報無しにその抽象化を綺麗に表現する。多相性は、カプセル化を１段階さらに勧める。多相性により、同じコードを異なるデータ型に対して使用すること、即ち多数の形態を１つのインタフェースで表すというアイデアが可能となる。従って、ソフトウェアコンポーネントは、別のコンポーネントを、そのコンポーネントが何であるかを正確に知らずに要求することができる。要求を受信したコンポーネントはその要求を解釈して、その変数およびデータに従って前記要求の実行方法を見つけ出す。第３の原理は継承であり、継承により開発者は既存の設計およびコードを再利用することができる。この能力により、開発者はスクラッチから全てのソフトウェアを生成することを回避することができる。寧ろ、継承を通して、開発者は他のクラスの状態および反応の両方を継承および修正するサブクラスを導出することができる。

オブジェクト指向プログラミングモデルは、クラスベースのアプローチを通して定義されることがよくある。本システムでは、オブジェクトは状態と反応の両方を含むエンティティである。オブジェクトの状態と反応の両方はクラスにより定義され、クラスは特定の型のオブジェクトを識別する。クラス定義に基づいて生成されたオブジェクトは、動的な型で反映されたクラスのインスタンスと見なされる。従って、クラスは、オブジェクトが含みうるデータ（例えば、状態）、および前記オブジェクトが実施可能な方法、関数、または反応を指定する。方法は、関連オブジェクトの内部状態を、その中に含まれるデータを変更することで修正するように動作する。オブジェクト内のデータおよび方法の組み合わせは、オブジェクト指向プログラミングではカプセル化と称されることがよくある。カプセル化は、オブジェクトに関連付けた良く定義された方法によってのみ変更されるオブジェクトの状態を与える。オブジェクトの反応は上記の良く定義されたロケーションおよびインタフェースに制限するとき、オブジェクト内の変更（例えば、コードの修正）がシステム内の他のオブジェクトおよび要素に対して及ぼす影響は最小である。

オブジェクト指向プログラミングに関する現在の欠点は、既存のオブジェクト、アプリケーションコンテキスト、等に基づいて新規のオブジェクトを自動的に生成することが困難であること、および既存のオブジェクトの修正（例えば、既存オブジェクト間の関係の修正）がさらに困難であることである。それどころか、熟練プログラマは複数の追加オブジェクトを生成しなければならず、この場合、それぞれのオブジェクトは別々のコンテキストに利用される。オブジェクト指向プログラミングの既存のフレームワークでは、カスタマイズした戦略をオブジェクトの合成に関連して実装することができない。

以下で簡単な要約を与え、クレーム主題のいくつかの態様の基本的な理解を与える。本要約は広範的な概要ではなく、本要約はクレーム主題の主要な要素／本質的な要素を特定すること、またはクレーム主題の範囲を表すことは意図していない。本要約の唯一の目的は、本発明のいくつかの簡略化された概念を、後述するより詳細な説明に対する前置きとして提示することである。

本明細書で説明するものは、アプリケーションに関連付けた１つまたは複数のオブジェクトを合成することに関連して使用しうる拡張可能なフレームワークであり、オブジェクトは、オブジェクト指向プログラミングに従う。従来のフレームワークとは対照的に、以下で説明する主張したフレームワークにより、様々な合成戦略をユーザが生成および実装することができる。本明細書で使用する合成という用語は、新規オブジェクトの生成、新規オブジェクトに関連する関係の定義、既存オブジェクトに関連する関係の定義、等を指す。オブジェクトの合成はいくつかの具体的な例を含むことができ、その例としては、適切なオブジェクトイニシャライザを起動することで新規のオブジェクトインスタンスをメモリ内に生成すること、オブジェクトと他の新規または既存のオブジェクトとの間の関係を確立すること、内部オブジェクト状態を修正することまたは内部状態に対して方法を起動すること、等がある。合成は、概念的にはターゲットオブジェクトとコンテキストを含み、コンテキストとはアプリケーション内の既存エンティティを表すために利用する用語である。例えば、これらのエンティティは、既存のオブジェクトインスタンス、ポリシーおよび型定義、アプリケーション構成、等を含むことができる。コンテキストに基づいて、様々な戦略を実装して特に１つまたは複数のオブジェクトを合成することができる。

より詳細には、合成戦略は或る特定の合成スタイルまたは合成部分に関与することができる。合成戦略は（合成戦略がそのタスクを完了できるようにするため）、上記戦略の実行の前、最中、または後に、異なる合成戦略または一連の別々の合成戦略の実行に依存してもよい。従って、合成戦略の反応はその実装によってのみ定義されることが理解できる。さらに、合成戦略は、外部エンティティがその反応を（一時的または永続的に）、プログラム的、宣言的、または構成ベースの手段により与えうる１つまたは複数のポリシーを通して修正可能とすることができる（が、そのように要求はされない）。これらの合成戦略を１つまたは複数のプログラマにより生成し、アプリケーションに実行時に適用することができる。この場合、決定したコンテキストに基づいて合成戦略を実行する。さらに、決定したコンテキストに基づいて合成戦略を特定の順序で実行することができる。例えば、段階に分類した一連の逐次的な合成戦略として合成戦略を実行することができ、従って複数の戦略が同一のオブジェクトおよびコンテキストに作用することができる。さらに、コンテキストおよびアプリケーションが必要とする場合、戦略を並行に実行することができる。

特定の例では、アプリケーションを展開することができ、アプリケーションはオブジェクト指向プログラミングにより書かれる。アプリケーションを書いた後、特定のオブジェクトを上記アプリケーション内部で合成することが望ましいであろう。従って、合成戦略を上記合成に関連して生成することができる。この場合、合成戦略はアプリケーションまたはコンテキストに影響しない。アプリケーションの実行時に、合成戦略および決定したコンテキストに従って合成戦略を実行し、オブジェクトを合成することができる。

前述および関連する目標を達成するため、或る例示的な態様を以下の説明および添付図面に関連して説明する。しかしながら、これらの態様はクレーム主題の原理を使用可能な少数の様々な方法を示すに過ぎず、クレーム主題は全ての上記態様およびそれらの等価物を含むよう意図している。他の利点および新規特徴は、図面と関連して考慮すると、以下の詳細な説明から明らかであろう。

図面を参照してクレーム主題を説明する。図面を通して、同様な参照番号を用いて同様な要素を指す。説明の目的のため、以下の記述では多数の具体的な詳細を説明してクレーム主題の徹底的な理解を与える。しかしながら、クレーム主題をこれらの具体的な詳細なしに実践できることは明らかであろう。他の事例では、公知の構造および装置をブロック図の形で示して、本発明の説明を容易にする。

本出願で使用する際、用語「コンポーネント」および「システム」は、コンピュータ関連の実体を指すよう意図している。コンピュータ関連の実体は、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれかである。例えば、コンポーネントは、プロセッサ上で実行中のプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、およびコンピュータであることができるがこれらに限らない。例示として、サーバ上で実行中のアプリケーションおよびサーバの両方はコンポーネントであることができる。１つまたは複数のコンポーネントは、プロセスおよび／または実行スレッド内に存在すること、コンポーネントを或るコンピュータ上に局所化すること、および／またはコンポーネントを２つ以上のコンピュータ間で分散させることができる。「例示的な」という単語は、本明細書では、例、事例、または実例を意味するよう用いる。「例示的」として本明細書で説明する任意の態様または設計は、他の態様または設計に対して好適または有利であるとは必ずしも解釈されない。

さらに、クレーム主題の態様を、コンピュータを制御するソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組合せを製造するための標準的なプログラミングおよび／またはエンジニアリング技術を用いた方法、装置、または製品として実装して、本発明の様々な態様を実装することができる。本明細書で用いる「製品」という用語は、任意のコンピュータ読取可能装置、キャリア、または媒体からアクセス可能なコンピュータプログラムを含むよう意図している。例えば、コンピュータ読取可能媒体は磁気記憶装置（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップ．．．）、光ディスク（例えば、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）．．．）、スマートカード、およびフラッシュメモリ装置（例えば、カード、スティック、キードライブ．．．）を含むことができるがこれらに限らない。さらに、搬送波を使用して、電子メールの送受信あるいはインターネットまたはローカルエリアネットワーク（ＬＡＮ）のようなネットワークのアクセスで用いられるようなコンピュータ読取可能な電子データを運搬できることは当然理解されるであろう。勿論、当業界の技術者は、本発明で説明したものの範囲または精神から逸脱することなく多数の修正を本構成に加えうることを理解するであろう。

図面を参照してクレーム主題を説明する。図面を通して、同様な番号は同様な要素を表す。図１を参照する。拡張可能なオブジェクト合成システム１００を示してある。オブジェクトの合成は概念的には、ターゲットオブジェクトに対して、前記ターゲットオブジェクトに関連するコンテキストに少なくとも部分的に基づいて作用することを含む。コンテキストを特定のアプリケーション内の既存エンティティおよび上記エンティティ間の関係として定義することができ、ターゲットオブジェクトを上記コンテキスト内で合成されているオブジェクトとして定義することができる。本明細書で用いる合成は、オブジェクト（例えば、ターゲットオブジェクト）の生成、および上記オブジェクトに関する関係の生成、既存オブジェクト（ターゲットオブジェクト）の受信、および既存オブジェクトと他のオブジェクトとの間の関係の生成、ターゲットオブジェクトに関連する既存関係の削除、ターゲットオブジェクトに関連する関係の変更、等を含むことができる。ターゲットオブジェクトに関する合成を、１つまたは複数のカスタマイズした合成戦略の利用を通して行うことができる。この場合、合成戦略の実装に関連するフレームワークにより、新規の合成戦略を追加することおよび上記戦略の使用を定義することが可能である。

さらにより詳細には、システム１００には受信コンポーネント１０２が含まれる。受信コンポーネント１０２は、カスタマイズした合成戦略を受信し、合成戦略をユーザ、プログラムから受信し、メモリ、ハードディスク、または任意の他の適切なロケーションから受信することができる。カスタマイズした合成戦略は、受信コンポーネント１０２により受信したいくつかの戦略の１つであることができ、オブジェクトを合成することに関連して行うことが可能な任意の適切なアクションを含むことができる。例えば、カスタマイズした合成戦略は特に、適切なオブジェクトイニシャライザを起動することでメモリ内に新規オブジェクトインスタンスを生成すること、オブジェクトと特定のコンテキスト内部における他の新規または既存オブジェクトとの間の関係を確立すること、内部オブジェクト状態を修正すること、オブジェクト上で方法を起動すること、ターゲットオブジェクト自体に作用せずにコンテキスト内部の他のオブジェクトに作用すること、に関連することができる。カスタマイズした合成戦略に関連しうるこのアクションリストは本質的に例であって限定的ではないことは当然理解されるはずである。受信した合成戦略は或る特定の合成スタイルに関与することができ、カスタマイズした合成戦略の前、カスタマイズした合成戦略の後、および／またはカスタマイズした合成戦略の最中に実行される他の関連合成戦略に依存して、受信したカスタマイズされた合成戦略の正確な実行を可能とすることができる。従って、合成戦略の反応を実装によってのみ決定することができ、合成戦略の反応により外部エンティティはその反応をポリシーとして一時的または永続的に変更することができる（が、そのように要求はされない）。これらポリシーを、プログラム的、宣言的、または構成ベースの手段により与えることができる。

カスタマイズした合成戦略は、受信コンポーネント１０２から実装コンポーネント１０４に中継させることができ、実装コンポーネント１０４は、上記合成戦略を、オブジェクト１０６を合成することに関連して利用する。例えば、実装コンポーネント１０４は、実行時にアプリケーションにより呼び出されることができ、アプリケーションは特定のカスタマイズされた合成戦略を要求し、それに関連するデフォルトのポリシーを指定することができる。受信コンポーネント１０２は、その後、上記の合成戦略を受け取ることができる。（上述の）コンテキストを次いで確認し、実装コンポーネント１０４に与えることができる。この場合、コンテキストにはアプリケーション内の一連のエンティティ、例えば既存のオブジェクトインスタンス、ポリシーおよび型定義、アプリケーション構成、等が含まれる。コンテキストおよびアプリケーション呼び出しに少なくとも部分的に基づいて、実装コンポーネント１０４は、オブジェクト１０６を合成することができる。従って、システム１００は、合成に関する拡張性を可能とすることが分かる。なぜならば、合成の実装に利用する合成戦略を、消費アプリケーションまたは他の合成戦略に対する変更を必要とせずに、独立に構築および利用できるからである。換言すれば、特定のコンテキスト内部にいくつかのルールが存在し、上記ルールオブジェクトを利用することを１回の呼び出しで生成および紐付けることができる。この場合、ルールは拡張可能かつポリシーにより決定されている。システム１００に類似したものとしてはファクトリラインがある。この場合、システム１００は、ユーザの意思でラインに追加の部分を与えることができる。これらの部分（戦略）を次いで実行時にアプリケーションにより消費および使用することができ、この場合、アプリケーションに関連するコンテキストは、使用すべき合成戦略、使用すべきポリシー、合成戦略の順序、等を決定することができる。

システム１００の利点を示すさらにより詳細な例では、アプリケーションに関連するいくつかのオブジェクトを十分に同様に紐付けることが望ましいであろう。この場合、上記の紐付けはカスタマイズされることが望ましい。静的なシステムと対照的に、システム１００により、１つまたは複数のカスタマイズされた合成戦略を生成すること、およびアプリケーションの変更または他の合成戦略の変更を必要とせずに上記の合成戦略を実装することが可能である。より詳細には、個人は、アプリケーションに関連するいくつかのオブジェクトに関して前記の紐付けが完全であることを望むであろう。従来のシステムでは、合成戦略がシステムに与えられないならば、それぞれのオブジェクトに対して紐付けを手動で行う必要があるであろう。しかしながら、システム１００により、所望の紐付けを実施し、（コンテキストにより決定可能な）適切なオブジェクト上での紐付けを自動的に実施するカスタマイズされた戦略を与えることができる。例えば、適切なカスタマイズされた戦略を、プログラマにより生成し、アプリケーションの実行時に受信コンポーネント１０２に与え、次いでコンテキストに基づいて実装コンポーネント１０４により実装することができる。

図２を参照し、拡張可能フレームワークを通して与えた合成戦略によりオブジェクト合成を促進するシステム２００を示す。システム２００には、受信コンポーネント１０２が含まれる。受信コンポーネント１０２は、複数のカスタマイズされた合成戦略を受け取り、この場合、上記合成戦略は、少なくともターゲットオブジェクト１０６を合成することに関する。上述のように、合成は様々な特定のアクションに関することができ、メモリ内にオブジェクトインスタンスを生成すること、オブジェクト間の関係を確立すること、内部オブジェクトの状態を修正すること、コンテキスト内の様々なオブジェクトに作用すること、等が含まれる。受信コンポーネント１０２をポリシーコンポーネント２０２に関連付けることができ、ポリシーコンポーネント２０２は、複数のカスタマイズされた合成戦略の各々に関してポリシーを定義および実装する。例えば、ポリシーは、永続的または一時的であることができる。永続的なポリシーは、複数の合成実行の間で一定のままであり、一時的なポリシーは、システム２００の単一の実行に対してのみ存在する。ポリシーコンポーネント２０２によりアプリケーションは、必要な合成戦略を指定し、デフォルトのポリシーを指定することができる。さらに、ポリシーコンポーネント２０２は、プログラム的、宣言的、または構成ベースの命令に少なくとも部分的に基づいて、カスタマイズされた合成戦略に関してポリシーを定義することができる。さらに、一時的なポリシーを使用して、カスタマイズされた合成戦略に特に関連付けたポリシーを上書きすること、または拡張することのいずれかが可能である。さらに、ポリシーコンポーネント２０２は、ターゲットオブジェクト１０６に関連する呼び出し間の戦略に関連付けたポリシーを変更することができる。この柔軟性は、従来のシステムでは実現不可能である。

受信コンポーネント１０２を順序付けコンポーネント２０４とさらに関連付けることができ、順序付けコンポーネント２０４は、複数のカスタマイズされた合成戦略の実装順序を記述する。さらに、順序付けコンポーネント２０４をコンテキストコンポーネント２０６と関連付けることができ、コンテキストコンポーネント２０６は順序付けコンポーネント２０４に、オブジェクト１０６に関連するコンテキストを与える。上述のように、コンテキストは、既存のオブジェクトインスタンス、ポリシーおよび型定義、アプリケーション構成等のようなターゲットオブジェクト１０６を含むアプリケーション内のエンティティを含むことができる。さらに、既存のオブジェクトインスタンスは、ローカルまたはリモートであることができ、この場合、用語「リモート」は別のコンピュータ、ネットワーク、プロセス、等におけるオブジェクトを示す。コンテキストコンポーネント２０６は、コンテキストを決定し、それを順序付けコンポーネント２０４に与えることができ、ターゲットオブジェクト１０６の構成を達成するため、順序付けコンポーネント２０４は、コンテキストを利用して合成戦略の適用順序を決定することが採用される。順序付けコンポーネント２０４は、順序に関連する宣言的またはプログラム的な文を受信することもできる。さらに、順序付けコンポーネント２０４は、望むならば合成戦略を並行に動作させることができる。

合成戦略の決定したコンテキストおよび順序を次いで実装コンポーネント１０４に与えることができる。実装コンポーネント１０４は、アプリケーションの実行時に戦略を特定の順序で実行させることができる。従って、柔軟かつ堅牢なオブジェクト合成システムが上記図面で説明したコンポーネントを通して可能となると決定することができる。

図３を参照し、ターゲットオブジェクト１０６を合成することに関連して上述した１つまたは複数の態様を利用する例示的システム３００を示してある。システム３００には受信コンポーネント１０２が含まれ、受信コンポーネント１０２は、１つまたは複数のカスタマイズされた合成戦略を受け取る。例示的システム３００では、受信コンポーネント１０２が受信した合成戦略はターゲットオブジェクト１０６を構築することに関連することができる。受信コンポーネント１０２を実装コンポーネント１０４に関連付け、実装コンポーネント１０４は、ターゲットオブジェクト１０６に関連して受信した戦略を実装することができる。実装コンポーネント１０４は、オブジェクトビルダコンポーネント３０２を含むこと、および／またはオブジェクトビルダコンポーネント３０２と関連付けることができ、オブジェクトビルダコンポーネント３０２は、コード３０４をプログラマおよびクラス定義３０６から受信することができる。コード３０４と定義３０６を与えると、受信した戦略に従ってターゲットオブジェクト１０６をオブジェクトビルダコンポーネント３０２により構築することができる。上記の合成戦略の使用により、オブジェクト指向プログラマは、従来のフレームワークと比較して大幅に効率的な方法で、高度に複雑かつ困難なタスクを完了することができる。

システム３００は、さらにポリシーインターロゲータコンポーネント３０８を含むことができ、ポリシーインターロゲータコンポーネント３０８はユーザ定義のポリシーを受信および問い合わせることができる。例えば、ポリシーは戦略を１回使用するかまたはいくつかのインスタンスに対して使用するかを指定することができる。実装コンポーネント１０４は、さらにターゲットオブジェクト１０６に関連付けたコンテキストを定義および／または受信することができ、ここで、コンテキストは既存のオブジェクトインスタンス、ポリシーおよび型定義、アプリケーション構成、等のようなアプリケーション内の一連のエンティティを示す。システム３００は、実際の合成作業を１つまたは複数の合成戦略に委譲することにより複数の合成スタイルおよび要件を可能とする。例えば、それぞれの戦略は特定の合成スタイルに関与することができる。受信した戦略により、外部エンティティはその反応をポリシーとして変更することができる。この場合、ポリシーをプログラム的、宣言的、または構成ベースの手段により与えることができる。ポリシーインターロゲータコンポーネント３０８は、上記ポリシーを問い合わせて、上記ポリシーが永続的なポリシーおよび／または一時的なポリシーであるかどうかを決定することができる。永続的なポリシーは、複数の合成実行の間で一定のままであり、一時的なポリシーはビルダの単一の実行に対してのみ存在する。一時的なポリシーは、合成戦略に与えたポリシーを上書きまたは拡張することができる。

システム３００により実装された合成戦略を拡張することができ、この場合、拡張を独立に構築および使用することができる。さらに、拡張は独立または相互依存であることができる。システム３００の特定の例示的な使用では、ファクトリパターン、ビルダ、および責任の連鎖が良く理解され、既存の依存性注入コンテナおよびプロキシファクトリで示した合成問題を解決するために適用されている。システム３００は、合成の生じ方における拡張性を可能とする。なぜならば、消費アプリケーションまたは他の戦略の変更を必要とせずに、合成を実装する戦略を独立に構築および使用できるからである。

特別な例では、システム３００を．ＮＥＴのイベントに対してサポートすることができ、それによりクラスの作成者はイベントのトピックを指定するイベントをパブリッシャ属性で修飾することができる。別のクラスの作成者は、イベントハンドラを、同一のトピックを指定するサブスクライバ属性で修飾することができる。実行時に、本明細書で説明したフレームワークを使用して、呼び出しコードからの干渉を受けずにこれらクラスのインスタンスを生成および紐付けることができる。換言すれば、オブジェクトビルダコンポーネント３０２がクラスのインスタンスを生成および紐付けることができる。例えば、

public class PublisherClass
{
[EventPublisher(“MyTopic”)]
public event EventHandler MyTopicEvent;

//イベントを発生させる事を行う。
}

public class SubscriberClass
{
[EventSubscriber(“MyTopic”)]
public void HandleMyTopicEvent(object sender, EventArgs e)
{
//イベントを処理
}
}

上記は、オブジェクト生成時に、システム３００により利用され、イベントのハンドラへの紐付けを実施可能な例示的戦略を示す。
別の例では、定義３０６は以下のＣ＃のクラス定義を含むことができる。

public class ParentClass
{
public ChildClass child;
public ParentClass(ChildClass child)
{
this.child = child;
}
public ChildClass Child
{
get{ return child;}
}
}
public class ChildClass
{
}

受信した戦略を使用してクラスを与えることができ、前記クラスにより以下の例示的コード３０４は、ＣｈｉｌｄＣｌａｓｓのインスタンスで埋めたＰａｒｅｎｔＣｌａｓｓの新規インスタンスを自動的に生成することができる。

より詳細には、以下のテストケースは、ＯｂｊｅｃｔＢｕｉｌｄｅｒＣｏｎｔａｉｎｅｒと称するクラスを利用した上述の新規インスタンスの生成を示し、ＯｂｊｅｃｔＢｕｉｌｄｅｒＣｏｎｔａｉｎｅｒはクレーム主題の実装を与える。前記の実装に、単純なコンストラクタベースの依存性注入を与える一連の戦略を与えることができる。

[Test]
public void ConstructorDependencyInjectionTest()
{
ObjectBuilder builder = new ObjectBuilder();
ParentClass parent = builder.Build<ParentClass>();
Assert.IsNotNull(parent.Child);
}

この例を拡張すると、上記コード（ビルディングコード）を、更なる戦略を追加することで拡張することができ、前記戦略は反映を使用して、属性付き方法を発見し、その方法を実行する。

public class SomeClass
{
Public bool MethodInvoked = false;
[InvokeMethod]
Public void DoSomething()
{
MethodInvoked = true;
}
}

[Test]
public void MethodInvocationStrategyTest()
{
ObjectBuilder builder = new ObjectBuilder();
Builder.AddStrategy(new MethodInvocationStrategy());

SomeClass result = builder.Build<SomeClass>();

Assert.IsTrue(result.MethodInvoked);
}

上記ビルダの使用前に戦略をビルダに追加することによりビルダの反応を迅速かつ容易に修正したことが分かる。

前述の例から、システム３００は、戦略を実装してタスクを実施できることを決定することができる。前記タスクには例えば、コンストラクタ依存性注入、セッタ注入、コンテナへの登録および格納、コンテナからの検索、型マッピング、属性の反映、プロキシの返却、および他の適切なタスクがある。上で示した単純な戦略に加え、いくつかの戦略は構成すべきポリシーを使用することができる。例えば、特定のインスタンスにおけるユーザはポリシーを使用していくつかの戦略を構成することができる。例えば、ユーザは特定のプロパティにセッタ導入を実施したいかもしれない。この場合、ユーザは（ポリシーインターロゲータコンポーネント３０８により分析される）ポリシーを与え、戦略を実装コンポーネント１０４によりどのように実装すべきかを示すことができる。例えば、

public class Person
{
private string name;

public string Name
{
get{ return name;}
set{ name = value;}
}
}

[Test]
public void PropertyPolicyTest()
{
ObjectBuilder builder = new ObjectBuilder();
builder.AddStrategy(new PropertySetterStrategy());
builder.AddStrategy(new PropertyPolicy(“Name”,”John Doe”));

Person result = builder.Build<Person>();

Assert.AreEqual(“John Doe”, result.Name);
}

このポリシーは、ビルダの全ての実行に対して、「Ｎａｍｅ」という名前の文字列プロパティを有するクラスが「Ｊｏｈｎ Ｄｏｅ」に設定されるという点で、永続的なポリシーである。しかしながら、システム３００（および本明細書で説明した他のシステム）はビルダの単一の実行に対して利用されるポリシーをサポートできることが分かる。例えば、

[Test]
public void TransientPolicyTest()
{
ObjectBuilder builder = new ObjectBuilder();
builder.AddStrategy(new PropertySetterStrategy());

PropertyPolicy johnPolicy = new PropertyPolicy(“Name”,”John Doe”);
Person john = builder.Build<person>(johnPolicy);
PropertyPolicy samPolicy = new PropertyPolicy(“Name”,”Sam Smith”);
Person sam = builder.Build<person>(samPolicy);

Assert.AreEqual(“John Doe”, john.Name);
Assert.AreEqual(“Sam Smith”, sam.Name);
}

図４を参照し、オブジェクト指向プログラミングで生ずる共通パターンの集約およびカプセル化を促進するシステム４００を示してある。システム４００には、戦略を受信する受信コンポーネント１０２と、上記戦略をアプリケーションの実行時に実装する実装コンポーネント１０４とが含まれる。システム４００の１つの利用において、戦略は、コンストラクタ依存性注入に関連することができ、コンストラクタ依存性注入は、クラスのコンストラクタの要求を実行時に発見すること、これらの要求を解決して、抽出または生成する必要があるオブジェクトを決定すること、およびオブジェクト自身の生成時にそれらをオブジェクトのコンストラクタに渡すことに関連付けられる。オブジェクト指向プログラミングにおけるコンストラクタは、オブジェクトの新規インスタンスの生成に利用される方法であり、特定のパラメータを要求することができる。コンストラクタ依存性注入の意図は、コンストラクタが必要とする方法を推論でき、その結果、クラスを消費する開発者が上記方法を明示的に定義する必要がないということである。従って要件は、オブジェクトの生成時に、推論したパラメータリストに基づいてコンストラクタ方法呼び出しに注入され、この場合、実装コンポーネント１０４に関連付けた機械学習コンポーネント４０２が推論結果を生成することができる。

本明細書で使用するとき、用語「推論」は、一般に、システム、環境、および／またはユーザの状態をイベントおよび／またはデータを通して取得した一連の観測から理由付けし推論するプロセスを示す。例えば、推論を使用して特定のコンテキストまたはアクションを識別でき、または状態の確率分布を生成することができる。推論は確率的であることができ、即ち推論はデータおよび事象を考慮した、着目する状態の確率分布の計算結果であることができる。推論は、高レベルな事象を一連の事象および／またはデータから構成するために用いる技術を指すこともできる。上記の推論の結果、事象が時間的に密接に相関するか否かに関わらず、ならびに事象およびデータが１つまたはいくつかの事象およびデータ源から来るか否かに関わらず、新規の事象またはアクションが一連の観測した事象および／または格納した事象データから構築される。様々な分類の枠組みおよび／またはシステム（例えば、サポートベクトルマシン、ニューラルネットワーク、エキスパートシステム、ペイジアンネットワーク、ファジーロジック、データフュージョンエンジン、．．．）を、自動的なアクションおよび／または推論したアクションの実施に関連して使用することができる。

或る特定の例では、推論は戦略およびポリシーを通して制御可能である。従って、推論は、コンストラクタのパラメータに適用可能な属性の宣言を分析することに達成される。別の例では、機械学習コンポーネント４０２により、（コンテキストの分析において）オブジェクトの型を簡単に検査することで推論を行うことができる。さらに、メタデータを（戦略に対するアドバイスと理解できる）戦略に与えることができ、それにより機械学習コンポーネント４０２は、上記決定に関してより良い意思決定を行うことができる。例えば、メタデータを外部ファイル４０４（例えば、外部ＸＭＬ構成ファイル）の形で与えることができる。別の例では、メタデータは、プログラマによりコード内部に与えたアドバイスの形であることができる。さらに別の例では、メタデータを．ＮＥＴのような属性言語から取得することができる。このように、メタデータの受信および／または提供に適した適切な方法を考慮しており、それらが添付請求項の範囲にあるとして意図してある。さらに、システム４００をコンストラクタ依存性注入に関して説明するが、紐付け、セッタ注入、コンテナへの登録および格納、コンテナからの検索、型マッピング、属性の反映、プロキシオブジェクトの返却、等に関して推論を行うことができることは理解される。

図５−１３を参照し、クレーム主題に従う方法を一連の動作として説明する。いくつかの動作は、本明細書で図示および説明した他の動作と異なる順序および／または並列に行うことができるので、クレーム主題は動作順序により限定されないことは理解されるべきである。例えば、当業者は、方法を状態図のような一連の相関する状態または事象として代替的に表現できることを当然理解するであろう。さらに、クレーム主題に従い方法を実装するために、示した動作の全てが必要なわけではない。さらに、以降および本出願に渡って開示する方法を製品に記憶することができ、コンピュータへの上記方法の移植および転送を促進できることは、さらに理解されるべきである。本明細書で用いる製品という用語は、任意のコンピュータ読取可能装置、キャリア、または媒体からアクセス可能なコンピュータプログラムを含むよう意図している。

とりわけ図５を参照し、オブジェクト指向プログラミングに従う１つまたは複数のオブジェクトを合成する方法５００を示してある。方法５００は、５０２で始まり、５０４で複数の合成戦略を受け取る。これらの戦略をユーザによりカスタマイズすることができ、他の戦略に依存または相互依存させることができる。５０６で、ターゲットオブジェクトを合成する命令を受信する。例えば、アプリケーションの初期化により、合成を上記アプリケーションの実行時に行う要求が生ずる。５０８で、ターゲットオブジェクトに関連付けたコンテキストを分析することができ、この場合、コンテキストは、アプリケーションに関連付けた既存のエンティティ、関係、インスタンス、クラス、等に関連する。５１０で、複数の合成戦略の少なくとも１つを、コンテキストに少なくとも部分的に基づいて実行する。例えば、合成戦略は、オブジェクトの生成、参照の修正、関係の生成、または任意の他の適切なアクションに関連することができる。さらに、合成戦略は独立であるか、あるいは１つまたは複数の別の戦略に依存することができ、コンテキストおよび／またはポリシーに依存して特定の順序で実行することができる。次いで、方法５００は５１２で完了する。

図６を参照し、拡張可能フレームワークを通してオブジェクトを合成する方法６００を示してある。方法６００は、６０２で開始し、６０４で複数の合成戦略を受け取る。実際の合成作業を複数の戦略のサブセットに委譲することで複数の合成スタイルおよび要件をもたらすことができる。さらに、戦略の各々は、特定の合成スタイルに関連することができ、その作業の完了前後に実行する他の合成戦略に依存できるかまたは依存できない。６０６でアプリケーションを実行し、６０８でターゲットオブジェクトを合成する命令を受信する。例えば、命令をアプリケーションの実行時に自動的に生成することができる。さらに、ターゲットオブジェクトが現在存在しないが合成戦略を複数のオブジェクト上で実行するという点で、命令は汎用的であることができる（従って、戦略は汎用的に実行され、命令は最初特定のオブジェクトに関連しない）。６１０で、アプリケーションに関連するコンテキストを決定し、この場合コンテキストには上記アプリケーション内部のエンティティまたは上記アプリケーションに関連するエンティティと、アプリケーション構成が含まれる。６１２で、複数の合成戦略のうち少なくとも２つをコンテキストに少なくとも部分的に基づいて実行し、この場合、上記戦略を並列または逐次（特定の順序）に実行することができる。例えば、コンテキストに依存して、第１の合成戦略は第２の合成戦略が上記の第１の戦略に先行することを要求することができる。従って、第２の合成戦略は、第１の合成戦略の前に実装されるべきである。同様に、第１の合成戦略は、第２の合成戦略が並列に実行されることを要求することができる。方法６００は次いで６１４で完了する。

図７−１３をまとめて参照し、戦略を通して実施する様々なタスクを説明する。別々に示してあるが、当業者はこれらの図面で説明する任意または全ての方法の組合せに関連する多数の戦略を与えうることを当然理解するであろう。特に図７を参照し、１つまたは複数の戦略を利用することでコンストラクタ依存性注入を行う方法７００を示す。方法７００は７０２で開始し、７０４で合成戦略を受け取り、この場合、戦略はコンストラクタ依存性注入と関連して利用するよう意図している。７０６で、ターゲットオブジェクトに関連するコンテキストを分析する。方法７００では、ターゲットオブジェクトは、生成することが望ましいオブジェクトインスタンスであることができる。７０８で、コンストラクタ依存性注入を１つまたは複数の受信した戦略に従って実施する。上述のように、コンストラクタ依存性注入は、クラスのコンストラクタの要求を実行時に発見すること、上記要求を解決して抽出または生成すべきオブジェクトを決定すること、および次いで上記オブジェクトの生成時に上記オブジェクトをターゲットオブジェクトのコンストラクタに渡すことに関連する。オブジェクト指向プログラミングにおけるコンストラクタは、オブジェクトの新規インスタンスの生成に利用される方法であり、パラメータを受け取ることができる。戦略を、コンストラクタに渡されるものを自動的に推論できるように設計することができ、この場合、推論は戦略およびポリシーを通して制御可能である。方法７００は７１０で完了する。

図８を参照し、戦略を利用することでセッタ注入を行う方法８００を示す。方法８００は８０２で開始し、８０４で合成戦略を受け取り、この場合、上記戦略をセッタ注入と関連して使用することができる。セッタ注入は、プロパティを設定することおよび生成したオブジェクト上で方法を呼び出すことに自動的に関連する。セッタ注入は、セッタ注入に関して未解決のオブジェクトが既に存在することを除いて、コンストラクタ依存性注入と同様である。しかしながら、設定すべきプロパティおよび呼び出すべき方法を推測することは、推論を通して達成することができる。上述のように、上記推論はコンテキストにおけるオブジェクトの型の分析、（例えば、ＸＭＬ構成ファイル、開発者が与えたコード、．．．における）前記オブジェクトに関連付けたメタデータの分析に基づくことができる。８０６で、ターゲットオブジェクトに関連付けたコンテキストを分析する。例えば、コンテキストの分析により、上述の推論に関連して利用されるメタデータを与えることができる。８０８で、セッタ注入をターゲットオブジェクト上で実施する。方法８００は次いで８１０で完了する。

図９を参照し、戦略に基づいてコンテナにオブジェクトを登録し、それを格納する方法９００を示す。方法９００は９０２で開始し、９０４で戦略を受け取る。戦略はターゲットオブジェクトを登録することに関連することができ、この場合、上記オブジェクトは新規に作成され、および／または既存（オブジェクトはターゲットオブジェクトである）であることができる。９０６で、上記オブジェクトに関連付けたコンテキストを分析して、ターゲットオブジェクトに関連するメタデータを取得する。メタデータを次いで戦略に関連して使用することができる。９０８で、ターゲットオブジェクトの登録および格納を戦略に従って実施する。コンテナへのオブジェクトの登録および格納は、将来の利用のためオブジェクトを覚えておくべきであるとシステムに通知することを示す。従って、検証によりオブジェクトへの要求を解決するとき、コンテナを解析して、既存のオブジェクトが特定のニーズに対して適切であるかどうか、または新規オブジェクトを生成することが望ましいかどうかを決定することができる。上述のように、戦略を１つまたは複数の推論と関連付けること、分析したメタデータに従って実行すること、および／または特定の命令に従って操作することが可能である。例えば、オブジェクトを登録および格納すべきとプログラマが明示的に記述する場合、戦略をそれに従って実行することができる。方法９００は次いで９１０で完了する。

図１０を参照し、受信した戦略に基づいてコンテナ内部のオブジェクトを検索する方法１０００を示す。方法１０００は１００２で開始し、１００４でコンテナ内部のオブジェクト（例えば、ターゲットオブジェクト）の検索に関連する戦略を受信する。１００６で、ターゲットオブジェクトに関連付けたコンテキストを分析し、１００８でコンテナからのオブジェクト検索を戦略に従って実施する。コンテナからオブジェクトを抽出することは、推論、メタデータ、明示的な命令、またはそれらの組合せを通して、オブジェクトをコンテナから抽出すべきかどうか、または新規オブジェクトを生成すべきかどうかを決定することに関連する。方法１０００は１０１０で完了する。

図１１を参照し、或る戦略を与えた型マッピングを実施する方法１１００を示す。方法１１００は１１０２で開始し、１１０４で型マッピングに関連する合成戦略を受け取る。型マッピングはインタフェースおよび具象クラスに関連し、ここで、インタフェースは特定のクラスに関連するパブリック方法の定義である。多相性により、別のクラスは、与えられているオブジェクトがインタフェースに従うことを知るだけでよい。より詳細には、オブジェクトの型は、上記オブジェクトが特定の方法に関連付けられる限り無関係であることができる。さらに、型マッピングは、要求された型をより具体的な具象型に変換することに関連することができる。１１０６で、コンテキストをターゲットオブジェクトに関して分析し、１１０８で型マッピングを戦略に従って実施する。方法１１００は次いで１１１０で完了する。

図１２を参照し、受け取った合成戦略に従って属性反映を実施する方法１２００を示す。方法１２００は１２０２で開始し、１２０４で属性反映に関連するカスタマイズされた合成戦略を受け取る。属性反映は、構築されているクラス上で反映することにより、１つまたは複数の戦略の自動的な発見および構成を可能とする。これは．ＮＥＴのような、属性をサポートする任意の言語を利用して行うことができる。１２０６で、ターゲットオブジェクトに関連付けたコンテキストを分析する。本例では、コンテキストはターゲットオブジェクトに関連付けた特別なクラスであることができる。１２０８で、受信した戦略に従って属性反映を実施し、方法１２００は次いで１２１０で完了する。

図１３を参照し、プロキシオブジェクトを返す方法１３００を示す。プロキシオブジェクトを、ターゲットオブジェクトで宣言した方法の異なる実装を与えるオブジェクトとして返すことができる。プロキシは当業界で公知であるが、従来は戦略の利用を通してプロキシを行うことはできなかった。方法１３００は１３０２で開始し、１３０４でオブジェクトのプロキシを与えることに関する合成戦略を受け取る。１３０６でオブジェクト（ターゲットオブジェクト）に関連付けたコンテキストを分析し、１３０８でプロキシオブジェクトを戦略に従って与える。方法１３００は次いで１３１０で完了する。

主題の本発明の様々な態様に対して更なるコンテキストを与えるため、図１４および以下の議論は、本発明の様々な態様の実装に適した動作環境１４１０の簡潔で、一般的な説明を与えることを意図している。本発明を、１つまたは複数のコンピュータあるいは他の装置により実行されるプログラムモジュールといったコンピュータ実行可能命令の一般的なコンテキストで説明するが、当業界の技術者は本発明を他のプログラムモジュールと組み合わせて、ならびに／またはハードウェアおよびソフトウェアの組合せとして実装することもできることを認識するであろう。

しかしながら一般に、プログラムモジュールには、特定のタスクを実施するかまたは特定のデータ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等が含まれる。動作環境１４１０は、適切な動作環境の１つの例に過ぎず、本発明の使用範囲または機能範囲に関する任意の限定を示唆するようには意図していない。本発明との併用に適した他の良く知られたコンピュータシステム、環境、および／または構成は、パーソナルコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能消費家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたはデバイスを含む分散コンピューティング環境、等を含むがこれらに限らない。

図１４を参照し、本発明の様々な態様を実装する例示的な環境１４１０には、コンピュータ１４１２が含まれる。コンピュータ１４１２には、演算装置１４１４、システムメモリ１４１６、およびシステムバス１４１８が含まれる。システムバス１４１８は、システムコンポーネントを演算装置１４１４に接続するのに、システムメモリ１４１６を含むがこれに限らない。演算装置１４１４は、様々な利用可能なプロセッサのうち任意のものであることができる。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャを演算装置１４１４として使用することもできる。

システムバス１４１８は、数種のバス構造（複数）のうち任意のものであることができ、バス構造には、メモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／または様々な利用可能なバスアーキテクチャのうち任意のものを用いるローカルバスが含まれる。バスアーキテクチャは、８ビットバス、業界標準アーキテクチャ（ＩＳＡ）、マイクロチャネルアーキテクチャ（ＭＳＡ）、拡張ＩＳＡ（ＥＩＳＡ）、統合ドライブエレクトロニクス（ＩＤＥ）、ＶＥＳＡローカルバス（ＶＬＢ）、周辺機器相互接続（ＰＣＩ）、ユニバーサルシリアルバス（ＵＳＢ）、アドバンストグラフィックポート（ＡＧＰ）、パーソナルコンピュータメモリカード国際協会バス（ＰＣＭＣＩＡ）、および小型コンピュータシステムインタフェース（ＳＣＳＩ）を含むがこれらに限らない。システムメモリ１４１６には、揮発性メモリ１４２０および不揮発性メモリ１４２２が含まれる。基本入出力システム（ＢＩＯＳ）は、例えば起動時にコンピュータ１４１２内の要素間での情報を転送する基本ルーチンを含み、不揮発性メモリ１４２２に記憶される。限定ではなく例として、不揮発性メモリ１４２２は、読取専用メモリ（ＲＯＭ）、プログラム可能ＲＯＭ（ＰＲＯＭ）、電気的プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリを含むことができる。揮発性メモリ１４２０には、外部キャッシュメモリとして動作するランダムアクセスメモリ（ＲＡＭ）が含まれる。限定ではなく実例として、ＲＡＭは、同期ＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、同期ＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲ ＳＤＲＡＭ）、拡張ＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンクＤＲＡＭ（ＳＬＤＲＡＭ）、およびダイレクトラムバスＲＡＭ（ＤＲＲＡＭ）のような多数の形態で利用可能である。

コンピュータ１４１２には取り外し可能／取り外し不能、揮発性／不揮発性コンピュータ記憶媒体も含まれる。図１４は例えばディスク記憶１４２４を示す。ディスク記憶１４２４は、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、ジャズドライブ、ジップドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックのような装置を含むがこれらに限らない。加えて、ディスク記憶１４２４は、他の記憶媒体と独立な記憶媒体または他の記憶媒体と組み合わせた記憶媒体を含むことができる。記憶媒体は、コンパクトディスクＲＯＭ装置（ＣＤ−ＲＯＭ）のような光ディスクドライブ、ＣＤ記録可能ドライブ（ＣＤ−Ｒドライブ）、ＣＤ書き換え可能ドライブ（ＣＤ−ＲＷドライブ）またはデジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）を含むがこれらに限らない。ディスク記憶装置１４２４のシステムバス１４１８への接続を促進するため、インタフェース１４２６のような取り外し可能または取り外し不能インタフェースを一般に使用する。

図１４で、ユーザと適切な動作環境１４１０で説明した基本的なコンピュータリソースとの間の中間物として動作するソフトウェアを説明することは理解されるべきである。上記ソフトウェアには、オペレーティングシステム１４２８が含まれる。オペレーティングシステム１４２８は、ディスク記憶１４２４に記憶することができ、コンピュータシステム１４１２のリソースを制御および割り当てるよう動作する。システムアプリケーション１４３０は、システムメモリ１４１６内またはディスク記憶１４２４上のいずれかに記憶したプログラムモジュール１４３２およびプログラムデータ１４３４を通して、オペレーティングシステム１４２８によるリソース管理を利用する。本発明を様々なオペレーティングシステムまたはオペレーティングシステムの組合せで実装できることは理解されるべきである。

ユーザは入力装置（複数）１４３６を通してコンピュータ１４１２に命令または情報を入力する。入力装置１４３６は、マウスのようなポインティングデバイス、トラックボール、スタイラスペン、タッチパッド、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラ、等を含むがこれらに限らない。これらおよび他の入力装置は、インタフェースポート（複数）１４３８経由でシステムバス１４１８を通して演算装置１４１４に接続する。インタフェースポート（複数）１４３８には例えば、シリアルポート、パラレルポート、ゲームポート、およびユニバーサルシリアルバス（ＵＳＢ）が含まれる。出力装置（複数）１４４０は、入力装置（複数）１４３６と同種のポートのいくつかを使用する。従って、例えば、ＵＳＢポートを使用してコンピュータ１４１２への入力を与え、コンピュータ１４１２からの情報を出力装置１４４０に出力することができる。出力アダプタ１４４２を与えて、他の出力装置１４４０の中にモニタ、スピーカ、およびプリンタのような特殊なアダプタを要するいくつかの出力装置１４４０があることを示す。出力装置１４４２には、限定ではなく例示として、出力装置１４４０とシステムバス１４１８との間の接続手段を与えるビデオおよびサウンドカードが含まれる。他の装置および／または装置のシステムは、リモートコンピュータ（複数）１４４４のような入力および出力ケイパビリティの両方を与えることに留意すべきである。

コンピュータ１４１２は、リモートコンピュータ（複数）１４４４のような１つまたは複数のリモートコンピュータに対する論理接続を用いてネットワーク環境で動作することができる。リモートコンピュータ（複数）１４４４はパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイスまたは他の共通ネットワークノード、等であることができ、一般にコンピュータ１４１２に関連して説明した要素の多数または全てが含まれる。簡単のため、メモリ記憶装置１４４６のみをリモートコンピュータ（複数）１４４４とともに示してある。ネットワークインタフェース１４４８を通してリモートコンピュータ（複数）１４４４をコンピュータ１４１２に論理的に接続し、次いで通信接続１４５０経由で物理的に接続する。ネットワークインタフェース１４４８は、ローカルエリアネットワーク（ＬＡＮ）および広域ネットワーク（ＷＡＮ）のような通信ネットワークを含む。ＬＡＮ技術には光ファイバ分散データインタフェース（ＦＤＤＩ）、銅分散データインタフェース（ＣＤＤＩ）、イーサネット（登録商標）／ＩＥＥＥ ８０２．３、トークンリング／ＩＥＥＥ ８０２．５、等が含まれる。ＷＡＮ技術は、ポイントツーポイントリンク、統合サービスデジタルネットワーク（ＩＳＤＮ）およびその上の変形のような回線交換ネットワーク、パケット交換ネットワーク、ならびにデジタル加入者線（ＤＳＬ）を含むがこれらに限らない。

通信接続（複数）１４５０は、ネットワークインタフェース１４４８をバス１４１８に接続するために使用するハードウェア／ソフトウェアを指す。通信接続１４５０を説明の明確さのためコンピュータ１４１２内部に示してあるが、コンピュータ１４１２の外部にあってもよい。ネットワークインタフェース１４４８への接続に必要なハードウェア／ソフトウェアには、例示のみの目的で、通常の電話モデム、ケーブルモデムおよびＤＳＬモデム、ＩＳＤＮアダプタ、ならびにイーサネット（登録商標）カードのような内部および外部技術が含まれる。

図１５は、本発明が相互作用可能なサンプルコンピューティング環境１５００の略ブロック図である。システム１５００には、１つまたは複数のクライアント（複数）１５１０が含まれる。クライアント（複数）１５１０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であることができる。システム１５００には、１つまたは複数のサーバ（複数）１５３０も含まれる。サーバ（複数）１５３０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）であることができる。サーバ１５３０は、例えば、本発明を使用することで変換を実施するスレッドを収容することができる。クライアント１５１０とサーバ１５３０の間の可能な通信の１つは、２つ以上のコンピュータプロセス間で送信するよう適応させたデータパケットの形であることができる。システム１５００には通信フレームワーク１５５０が含まれる。通信フレームワーク１５５０を使用して、クライアント（複数）１５１０とサーバ（複数）１５３０との間の通信を促進することができる。クライアント（複数）１５１０に１つまたは複数のクライアントデータストア（複数）１５６０を動作可能に接続する。クライアントデータストア（複数）１５６０を使用して、クライアント（複数）１５１０に局所的に情報を記憶することができる。同様に、サーバ（複数）１５３０に１つまたは複数のサーバデータストア（複数）１５４０を動作可能に接続する。サーバデータストア（複数）１５４０を使用して、サーバ（複数）１５３０に局所的に情報を記憶することができる。

上述したことには、クレーム主題の例が含まれる。勿論、上記の主題を説明する目的で全ての考えうる構成要素または方法の組合せを記述することは不可能であるが、当業者は、多数の更なる組合せおよび並び替えが可能であることを理解するであろう。従って、クレーム主題は、添付請求項の精神および範囲にある全ての上記変更、修正、および変形を含むと意図している。さらに、用語「〜を含む」を詳細説明または請求項のいずれかで使用する限り、上記用語は「〜を備える」が請求項において移行語として使用されるときに解釈されるように、用語「〜を備える」と同様に包括的であると意図している。

特定のカスタマイズした戦略を与えたオブジェクトの合成を促進する、システムの高レベルなブロック図である。 複数の戦略を使用してターゲットオブジェクトの合成を促進するシステムのブロック図であり、戦略の順序は決定したコンテキストに少なくとも部分的に基づく。 拡張可能プログラミングフレームワークのブロック図である。 推論の生成を促進するシステムのブロック図である。 アプリケーション内のオブジェクトを合成する方法の代表的なフロー図である。 １つまたは複数のオブジェクトを合成することに関連して戦略の順序を決定する方法の代表的なフロー図である。 合成戦略に従ってコンストラクタ依存性注入を実施する方法を示す代表的なフロー図である。 合成戦略に従ってセッタ注入を実施する方法を示す代表的なフロー図である。 合成戦略に従ってターゲットオブジェクトをコンテナ内に登録および格納する方法を示す代表的なフロー図である。 合成戦略に従ってターゲットオブジェクトをコンテナ内から発見する方法を示す代表的なフロー図である。 合成戦略に従ってターゲットオブジェクトに関連する型マッピングを実施する方法を示す代表的なフロー図である。 合成戦略に従って属性反映をターゲットオブジェクトに関して実施する方法を示す代表的なフロー図である。 合成戦略に従ってプロキシオブジェクトを与える方法を示す代表的なフロー図である。 適切な動作環境を示す略ブロック図である。 サンプルコンピューティング環境の略ブロック図である。

Claims (15)

1. オブジェクトを使用するアプリケーションの実行中のコンテキストに基づき、自動的にオブジェクトを構築し、オブジェクト間の関係を自動的に定義するためのシステムであって、
   前記システムは、
   １つまたは複数のコンピュータ記録媒体と、
   プロセッサと
   を備え、
   前記１つまたは複数のコンピュータ記録媒体上に、
   プロセッサに実行されたときに、ターゲットオブジェクトに関連付けられたコンテキスト内で与えられたカスタマイズされた合成戦略を受信する受信コンポーネントであって、前記受信されカスタマイズされた合成戦略は、消費アプリケーションに変更を要求することなく、複数のカスタマイズされた合成戦略の他の戦略に変更を要求することなく、個別に構築され、使用される、受信コンポーネントと、
   前記ターゲットオブジェクトに関連付けられたコンテキストに少なくとも部分的に基づいて、前記ターゲットオブジェクトを作成するために、前記カスタマイズされた合成戦略を自動的に実装する実装コンポーネントであって、
   前記ターゲットオブジェクトに関連付けられた前記コンテキストは、前記ターゲットオブジェクトを使用する前記受信コンポーネント、及び、前記実装コンポーネントとは別の、前記消費アプリケーションの現在のコンテキストに基づくものであり、前記消費アプリケーションは、前記現在のコンテキストが前記消費アプリケーションの実行中のコンテキストに対応するように、実行され、
   前記カスタマイズされた合成戦略の実施に関連付けられたフレームワークは、新しくカスタマイズされた合成戦略の追加を許容し、それらの戦略の使用を定義し、その結果、前記ターゲットオブジェクトの作成が、前記消費アプリケーションの実行中に実行される、実装コンポーネントと、
   前記カスタマイズされた合成戦略を、前記ターゲットオブジェクトに関連付けられた前記コンテキストにより決定された順序で実行することを促進し、その結果前記カスタマイズされた合成戦略が、前記複数のカスタマイズされた合成戦略の他の戦略に関する異なる順序で実行するために、順序付けられる順序付けコンポーネントと、
   前記ターゲットオブジェクトに関連付けられた前記コンテキストを判定するコンテキストコンポーネントであって、前記ターゲットオブジェクトに関連付けられた前記コンテキストが、前記ターゲットオブジェクトに関連付けられた前記アプリケーションのコンテキストと、前記ターゲットオブジェクトに関連付けられた既存のオブジェクトと、前記既存のオブジェクト間の関係と、を含み、前記コンテキストは、前記アプリケーション、及び、前記消費アプリケーションの実行中のターゲットオブジェクトに関連するコンポーネントのセットであり、前記少なくとも１つの既存のオブジェクトは、リモートオブジェクトである、コンテキストコンポーネントと
   を備えることを特徴とするシステム。
2. 前記受信コンポーネントは、前記複数のカスタマイズされた合成戦略を受信することを特徴とする請求項１に記載のシステム。
3. 前記順序付けコンポーネントは、前記複数のカスタマイズされた合成戦略を、前記ターゲットオブジェクトに関連付けられたコンテキストに基づき実行することを促進することを特徴とする請求項２に記載のシステム。
4. 前記カスタマイズされた合成戦略は、永続的なポリシー、または一時的なポリシーであることを特徴とする請求項１に記載のシステム。
5. 前記ターゲットオブジェクトを合成することに関連して推論を使用するよう構成したことを特徴とする請求項１に記載のシステム。
6. 前記推論が、１つまたは複数の分析したメタデータおよび明示的な命令に少なくとも部分的に基づいて生成されたことを特徴とする請求項５に記載のシステム。
7. 前記推論を生成することに関連して使用される外部構成ファイルをさらに備えることを特徴とする請求項５に記載のシステム。
8. 実行アプリケーションの現在のコンテキストに基づき、オブジェクトを合成するためにプロセッサにより以下のコンピュータ実行可能動作を実行する拡張可能方法であって、
   アプリケーションの実行中に、前記アプリケーションからの呼び出しを受け取るステップであって、前記呼び出しは、少なくとも１つの合成戦略のための要求と、前記合成戦略に関連づけられたデフォルトのポリシーの指定とを含む、受け取るステップと、
   複数の合成戦略を受け取るステップと、
   前記実行アプリケーションのためにターゲットオブジェクトを合成する命令を受信するステップと、
   前記ターゲットオブジェクトに関連付けられたコンテキストを判定するステップであって、前記ターゲットオブジェクトに関連付けられたコンテキストは、前記アプリケーション内に存在し、前記アプリケーションに関連するエンティティのセットと、前記呼び出しが受信されたときに、実行中のアプリケーションとを含み、前記ターゲットオブジェクトに関連付けられたコンテキストは、前記ターゲットオブジェクトが合成される前記アプリケーションの少なくとも１つのコンテキストと、前記ターゲットオブジェクトに関連付けられた既存のオブジェクトと、前記既存のオブジェクト間の関係とを含み、前記少なくとも１つの既存のオブジェクトは、リモートオブジェクトである、判定するステップと
   を備えることを特徴とする方法。
9. 少なくとも２つの前記合成戦略を並列に実行するステップをさらに備えることを特徴とする請求項８に記載の方法。
10. 少なくとも２つの前記合成戦略を指定した順序で逐次的に実行するステップをさらに備えることを特徴とする請求項８に記載の方法。
11. 前記少なくとも１つの戦略を実行する際に、１つまたは複数のコンストラクタ依存性注入およびセッタ注入を実施するステップをさらに備えることを特徴とする請求項８に記載の方法。
12. 前記少なくとも１つの戦略を実行する際に、前記ターゲットオブジェクトをコンテナに登録するステップ、前記ターゲットオブジェクトをコンテナに格納するステップ、およびコンテナから前記ターゲットオブジェクトを抽出するステップ、のうち１つまたは複数を実施するステップをさらに備えることを特徴とする請求項８に記載の方法。
13. 前記少なくとも１つの戦略を実行する際に、前記ターゲットオブジェクトに関する型マッピングを行うステップ、および前記少なくとも１つの戦略を実行する際に、前記ターゲットオブジェクトに対してプロキシオブジェクトを与えるステップ、のうち少なくとも１つを実施するステップをさらに備えることを特徴とする請求項８に記載の方法。
14. 前記少なくとも１つの戦略を実行する際に、属性反映を実施するステップをさらに備える請求項８に記載の方法。
15. オブジェクトの合成を要求するアプリケーションの実行の間に、前記アプリケーションの現在のコンテキストに基づき、オブジェクト合成のための拡張可能なシステムであって、
    前記システムは、１つまたは複数のプロセッサと、
    前記１つまたは複数のプロセッサにより実行されたときに、前記拡張可能なシステムに、以下の方法を実行させるコンピュータ実行可能命令を記憶する１つまたは複数のコンピュータ記録媒体とを備え、前記方法は、
    アプリケーションの実行中に、前記アプリケーションからの呼び出しを受け取るステップであって、前記呼び出しは、少なくとも１つのターゲットオブジェクトの作成のための要求を開始する、受け取るステップと、
    一連の逐次的な合成戦略を受け取るステップであって、前記一連の合成戦略は、前記少なくとも１つのターゲットオブジェクトを構築することに関連する受け取るステップと、
    前記少なくとも１つのターゲットオブジェクトに関して、前記一連の合成戦略を実施するステップと、
    前記少なくとも１つのターゲットオブジェクトに関連付けられたコンテキストを判定するステップであって、前記少なくとも１つのターゲットオブジェクトに関連付けられた前記判定されたコンテキストは、前記ターゲットオブジェクトに関連付けられた前記アプリケーションの実行時の、前記アプリケーションの現在のコンテキストを含み、前記少なくとも１つのターゲットオブジェクトに関連付けられた前記判定されたコンテキストは、前記ターゲットオブジェクトに関連付けられた既存のオブジェクトと、前記既存のオブジェクト間の関係と、前記アプリケーション内で実行するオブジェクトインスタンスの識別子とを含み、前記コンテキストは、前記アプリケーションの実行時の、前記アプリケーション、及び、前記ターゲットオブジェクトに関連するコンポーネントのセットであり、前記少なくとも１つの既存のオブジェクトは、リモートオブジェクトである、判定するステップと、
    ポリシーを問い合わせるステップであって、前記ポリシーは、前記一連の合成戦略を実施するためのルールを指定し、その結果前記一連の逐次的な合成戦略が使用される順序を変更する、問い合わせるステップと、
    前記アプリケーションの実行中のコンテキストを考慮して、前記ポリシーの問い合わせにより判定された順序で、前記受け取られた一連の合成戦略に少なくとも一部は基づいて、前記少なくとも１つのターゲットオブジェクトを作成するステップであって、前記少なくとも１つのターゲットオブジェクトを作成するステップは、前記実行中の前記アプリケーションの前記コンテキストに基づき、同じ前記一連の合成戦略が前記実行中のアプリケーションの少なくとも２つの異なるコンテキストのために、異なる順序で順序付けられるように、前記一連の合成戦略を順序付けるステップを含む、作成するステップと
    を含むことを特徴とするシステム。

Images