Gecko Embedding Basics

インターフェース

XPCOM の核となる部分にこそ、インターフェースの構想があります。インターフェースは、全て特定の機能に関連した、一連のメソッド、属性、関連した定数の単純な記述です：それらのものを実装するクラスとは完全に違います。インターフェースは一種の契約（コントラクト）として供給します：特定のインターフェースをサポートするあらゆるオブジェクトは、それに記述されたサービスをそれが演じることを保証します。インターフェースを可能な限り言語間で平等に保つために、それは特別な言語、インターフェース定義言語 (Interface Difinition Language、IDL)、で書かれています。インターフェースのファイルはしばしば .idl ファイルとして参照されます。これらのファイルは、インターフェースの機能を明細に述べているのに加えて、インターフェースの IID、すなわち、そのグローバルに唯一な識別番号（ID 番号）を運びます。

Gecko 内でのコミュニケーションの多くは、これらの抽象的な構造の点で起きます（慣習から、それらの名前は nsISomething という形式に従います）。

//こう
void ProcessSample(nsISample* aSample) {
	aSample->Poke("Hello"); 
//こうではない
void ProcessSample(nsSampleImpl* aSample) {
	aSample->Poke("hello"); 

@status FROZEN

XPCOM の抽象のレベルはシステム内での大きな柔軟性を生みます。実装は必要な時に自由に変化します。しかし、はたらくためにはインターフェース自体は固定したままでなければなりません。Mozilla の初期の設計と開発期間全体を通じて、インターフェースはいくらか流動的であってきました。しかしプロジェクトが成熟してくるにつれて、ますます多くのインターフェースが FROZEN（凍結）と印を付けられました。印付けされたどんなインターフェースも将来変化しないと保証されています。

組み込み努力のカギとなる主要なインターフェースのほとんどは、現在凍結されています。しかし、あらゆるインターフェースを使う前に確かめるのは常に良い考えです。インターフェースの状態は .idl ファイルのコメントに一覧表にされています。凍結されたインターフェースは @status FROZEN と印が付けられています。あなたは mozilla 相互参照ツールを使って、lxr.mozilla.org/seamonkey/search?string=%40status+FROZEN に凍結されたインターフェースを探すことができます。凍結されるまでインターフェースはいつ何時変わるかもしれません。凍結過程について詳しい情報は、 組み込みプロジェクトのページ を見て下さい。

ひとたびインターフェースが凍結されたら、Gecko 組み込み API リファレンス に加えられます。

nsISupports

1つのオブジェクトが1つよりも多くのインターフェースをサポートできます。実際、基本的には全てのオブジェクトは、少なくとも2つのインターフェースをサポートします - 特別に役立つ何かをする最小限のインターフェースと、より一般的な目的を供給するインターフェース、nsISupports です。ある意味、nsIsupports は全ての XPCOM インターフェースの原型です。全てのインターフェースはそれから継承します。ほとんどは直接的に継承しています。 それは2つの主要機能を供給します - ランタイムタイプの発見とオブジェクトの寿命管理です。これは MSCOM の IUnknown と機能的には同一のものです。

オブジェクトは多様なインターフェースをサポートできるので、 1つのインターフェースへポインタをもつことや、異なったインターフェース - あなたがひょっとしたらそのインターフェースの機能を必要とするかもしれない - もまたサポートするかどうか知りたい、といったことは完全に可能です。 nsISupports の最初のメソッドである QueryInterface はまさにこれを行うものです。これは実際、「私はこのオブジェクトがタイプ A（インタフェース A に対応）のものであることを知ってるけど、タイプ B（インタフェース B に対応）でもあるかい？」といった質問ができます。

もしそれがそうである（または知っている）ならば、QueryInterface() は新たに要求されたインターフェースに縛りつけられたポインタを呼び出し元に返します。

void ProcessSample(nsISample* aSample) {
	nsIExample *example;
	nsresult rv;
	rv = aSample->QueryInterface(NS_GET_IID(nsIExample),(void **)&example);
	if (NS_SUCCEEDED(rv)) {
		example->DoSomeOperation();
		NS_RELEASE(example); //Release を呼び出すためにマクロを使用します
	}
}

XPCOM は実際にオブジェクトを生成するための間接的なメソッド、コンポーネントマネージャー（Conponent Manager）を使用しているから、そして同じオブジェクトへの - しばしば異なったインターフェースに縛りつけられた - 多様なポインタが存在できるから、呼び出し元がそれらのポインタがポイントする全てのオブジェクトを現在見失わないことは、急速に難しくなってきているかもしれません。オブジェクトはそれらが必要とするのよりもより長く、メモリー内のまわりに保たれている可能性があります、それがリークの原因となっているのですが。または、オブジェクトが早まって削除される可能性があります、それがポインタのダングリングの原因となっているのですが。nsISupports における残り２つのメソッド AddRef() と Release() は、この問題を処理するよう設計されています。ポインタが出てくるたびに、そのオブジェクトに対して AddRef() が呼び出され、内部カウンタを増やします。 ポインタがリリースされるたびに Release() が呼び出され、同じ内部カウンタを減らします。 カウンタが 0 に到達するとき、残っているオブジェクトへのポインタはなくなり、オブジェクトは安全に自身を削除します。オブジェクトの寿命の制御はオブジェクト自身の中で留まります。XPCOM の "賢い" ポインタ、nsCOMPtr、すなわちこの過程を自動でするのを助けるユーティリティーについての情報はここを見て下さい。

Object の生成

オブジェクトを生成することもまた、XPCOM では間接的な過程です。ちょうどインターフェースがグローバルな唯一の ID 番号 (IID) をもっているのと同じように、XPCOM のクラスはそれら自身の GUID （グローバルな唯一の ID 番号）すなわち CID が割り当てられます。加えて、XPCOM のクラスはまたテキストベースの ID、契約 ID（Contract ID）、と呼ばれるのもしばしば与えられます。これらの ID の一方またはもう一方は、実際にオブジェクトを作っている永続的な XPCOM コンポーネント、コンポーネントマネージャー、についてのメソッドへと通されます。（XPCOM ではモジュールと呼ばれている）クラスの新しいライブラリがシステムへと初めて導入されるとき、それは自身をコンポーネントマネージャーに登録しなければなりません。コンポーネントマネージャーはそれらが存在しているライブラリへ、それらの ID とともにクラスの地図を作っているレジストリを維持しています。

シングルトンオブジェクトによって供給された限られた数の永続的なサービスは、コンポーネントマネージャーの仲間、サービスマネージャーによって作られて、制御されています。コンポーネントマネージャーはそれ自体、そのような永続的なサービスの例です。

要約

XPCOM 内の機能は抽象的なインターフェースによって記述されています。そして、システムの部分間のほとんどのコミュニケーションは、それらのインターフェースの点で起こります。一方で、インターフェースを実装する基礎的なオブジェクトは、それが維持している相互参照レジストリに基づいたコンポーネントマネージャーによって、間接的に作られます。

全てのインターフェースによって共有された1つの機能とは、実行時（ランタイム）に基盤となるオブジェクトに対して他のインタフェースも実装しているかどうかを聞くことができるというものです。理論上では、ある1つのインターフェースは固定されて変更できません。しかし、Mozilla コードベース内でのこのステージでは、FROZEN と宣言されたインターフェースのみがはっきりと変化しないと保証されます。オブジェクトの寿命管理は加えられた、またはリリースされたオブジェクトへポインタの数を見失わない内部カウンタを通じて、オブジェクト自身の中で起こります。クライアントの唯一の責任はカウンタを増減することです。内部カウンタが 0 に達したとき、オブジェクトは自身を削除します。

nsCOMPtr

しかし、正しいタイミングで AddRef() と Release() を忘れずに呼び出すのが難しいこともあるかもしれません。 この過程をより簡単に、そしてより信頼できるようにするために、XPCOM は内蔵の "賢い" ポインタ、すなわち nsCOMPtr をもっています。このポインタはあなたのために AddRef() と Release() を呼び出すことの面倒をみます。可能な限り nsCOMPtr を使うことはあなたのコードをよりきれいに、そしてより効率よくするでしょう。その賢いポインタについて更なる情報は "完全な nsCOMPtr ユーザーマニュアル" を見て下さい。

Mozilla は実際に非常に多くの内蔵マクロ（慣習から、コード内に全て大文字で書かれています）とか、XPCOM でのコーディングの全過程をより簡単にすることができる nsCOMPtr のようなユーティリティーを提供します。これらの多くは下記のファイルに見つけられます：nsCom.h、nsDebug.h、nsError.h、nsIServiceManager.h、nsISupportsUtils.h。Mozilla はまたメモリの使用をたどるための他の開発ツールなどのものを提供します。これらについての更なる情報は http://www.mozilla-japan.org/performance/ に見つけられます。

更なる情報

XPCOM 全般についての更なる情報は XPCOM に見つけることができます。XPCOM コンポーネント群を作ることを一通り目を通すには、O'Reilly の Creating Applications with Mozilla の第8章を見て下さい。このトピックに完全に専念した新しい本、 Creating XPCOM Components もあります。COM システムへの基礎にある論理のいくつかのより完全な説明は、Don Box による Essential COM の最初の方の章で見つけることができます。それが特に MSCOM に焦点を置いている一方で、その本はそのようなオブジェクトモデルを使うために核となっている合理性のいくつかについての素晴らしい背景を提供します。