IAdaptableとは？（後編）

今まで謎だったIAdaptableインタフェース。これについてPlatform Plug-in Developer GuideのelementFactoriesの解説の中でIAdaptableインタフェースの説明が記載されているけど，最初に読んだときは「何いってんだ？」とちんぷんかんぷんだった。しかし，わかってしまえば（わかったつもりになってしまえば）なんてことはない。

ここでIAdaptableインタフェースが定義している唯一つのメソッドを紹介しよう。クラスオブジェクトを渡して，何らかのオブジェクトを得るというメソッドである。
　　Object getAdapter(Class adapter)
これだけみても「は？」って感じだが，Eclipseはこのメソッドが支えているといっても過言ではない。

Eclipseはプラグインの集合体で成り立っているわけで，プラグイン開発者がどんなプラグインを用意するかもわからない。しかし，プラットフォームはプラグインに対して，いろいろと要求を行わなければならない。例えば，テキストエディタのプラグインであれば，プラットフォームは「アウトラインビューはどうするの？」「検索や置換はどうするの？」などというように，プラットフォームはテキストエディタを補佐する機能をテキストエディタ自身から得なければならない。そこで活躍するのがIAdaptableインタフェースなのだ。

プラットフォームはテキストエディタに対して，「アウトラインビューとして何か提供できる？」って感じで，IContentOutlinePageクラスオブジェクトをgetAdapterメソッドに渡して呼び出す。テキストエディタの実装は，もしアウトラインビューを提供するのであればIContentOutlinePageの実装オブジェクトを生成して返せばいいし，提供しないのであればnullを返せばよい。もし実装オブジェクトを返したときは，プラットフォームがそれを検地してアウトラインビューを生成して表示してくれる。つまり，「これをくれ」→「じゃぁこれあげるよ」というコーディングになる。

もちろん別のやり方，例えばShowableOulineインタフェースを定義してそれをエディタが実装し，適切なアウトラインビューオブジェクトを返してもらって・・・って感じの仕組みでも問題はなさそうだけど，インタフェースの定義とはかなりきつい静的な制約になってしまうために，Eclipseの開発者はきっと避けたかったはず。それよりももっと柔軟性に富んだ仕組みにするためには，Windowsのメッセージ駆動みたいなやり方，つまりメッセージ（Classオブジェクト）を決まったオブジェクト(getAdapterメソッド)に送り込み処理を実行させて結果（getAdapterメソッドの戻り値）を得る，ということを実現したかったに違いない。これによって，パーツ間の祖結合が促進されるし，パーツ間の関係は実行時に行われるようになるのでバージョンアップ時にメッセージが変更されたとしてもプラグインが動作しなくなってしまうことはない（テキストエディタが結果として提供したオブジェクトがプラットフォームに無視されちゃうかもしれないけど）。プラットフォームとしては，エディタなどの対象物が最低限IAdaptableインタフェースで規定されたgetAdapterメソッドを備えていれば良いということになる。

試しにTextEditorのサブクラスを作って，getAdapterメソッドを以下のようにオーバーライドしてエディタをプラグインとして実行してみると，プラットフォームがテキストエディタに何を期待しているのかが見て取れる。

class HogeTextEditor extends TextEditor {
　　...
　　public Object getAdapter(Class adapter) {
　　　　System.out.println(adapter.getName());
　　　　return super.getAdapter(adapter);
　　}
}

オブジェクト間の関連について高いレベルで祖結合を実現した仕組みって感じかな。プラットフォームを支える基本的かつ柔軟な仕組みといえるけど，プラグイン開発者にとってはきっと「ひえぇ」って仕組みだろう。なぜなら，ドキュメントやサンプルプログラムなどに頼らないと，どんなクラスオブジェクトが飛んでくるかわからないからだ・・・。